Publicado por: Seprol | Categoria: Red Hat | Modernização de Infraestrutura
Tempo de leitura estimado: 6 minutos
Durante anos, a promessa da inteligência artificial em TI ficou restrita a uma função: ajudar. Sugerir um comando, completar um script, explicar um erro de log. Útil, sem dúvida. Mas ainda havia um humano no meio do caminho, copiando a sugestão, colando no terminal, confirmando a execução.
Isso está mudando. E a Red Hat acaba de dar um passo concreto nessa direção.
A Red Hat anunciou o MCP Server para o Ansible Automation Platform como feature em technology preview na versão 2.6.4 da plataforma. A proposta é direta: permitir que LLMs (Large Language Models, os modelos de linguagem por trás de ferramentas como Claude e ChatGPT) interajam diretamente com o Ansible para gerenciar infraestrutura por meio de linguagem natural.
Uma mudança de arquitetura, não apenas mais uma demo de laboratório.
O que é o MCP e por que ele importa aqui
MCP é a sigla para Model Context Protocol, um padrão aberto que define como agentes de IA se comunicam com ferramentas e sistemas externos. Em vez de cada ferramenta criar sua própria integração com cada modelo de linguagem, o MCP oferece uma camada comum, parecido com o que o LSP (Language Server Protocol) fez para editores de código e servidores de linguagem.
O MCP Server da Red Hat age como uma ponte entre o cliente de IA de sua escolha e o Ansible Automation Platform. Na prática, isso significa que ferramentas como Cursor, Claude ou VS Code passam a enxergar os recursos do Ansible (templates de jobs, inventários, credenciais, logs) como contexto disponível para o agente operar.
O resultado: você pode dizer “quais hosts do grupo produção falharam no último deploy?” e receber a resposta diretamente do inventário real, sem sair do seu ambiente de trabalho.
A questão que toda adoção de IA em TI precisa responder
Dar a uma IA a capacidade de executar ações em produção levanta uma pergunta legítima: quem controla o que ela pode fazer?
A resposta da Red Hat está na arquitetura de segurança do MCP Server, que opera em duas camadas sobrepostas. A primeira é a configuração do servidor em si: os administradores escolhem entre o modo somente leitura, ideal para monitoramento e consultas, ou o modo de leitura e escrita, que permite execução de jobs e mudanças reais no ambiente.
A segunda camada é o RBAC já existente no Ansible Automation Platform. O agente de IA herda as permissões do usuário conectado. Se aquele usuário não tem acesso para executar um playbook em produção, o agente também não tem. Não existe bypass.
Esse ponto é mais relevante do que parece. Boa parte da resistência à adoção de IA em ambientes corporativos não vem de ceticismo sobre a tecnologia em si, mas da percepção de que ela cria superfícies de risco novas e difíceis de auditar. Um modelo que opera dentro do RBAC já auditado pela equipe de segurança é um modelo cujo comportamento pode ser rastreado com as ferramentas que a empresa já usa.
O que os agentes conseguem fazer, na prática
O MCP Server disponibiliza seis conjuntos de ferramentas, cada um voltado para um perfil de uso diferente:
- Gerenciamento de jobs: listar templates disponíveis, disparar automações e acompanhar o status em tempo real.
- Gerenciamento de inventário: consultar hosts, verificar grupos e checar fatos do sistema.
- Monitoramento: recuperar logs de jobs, investigar tarefas com falha e verificar a saúde geral do ambiente.
- Gestão de usuários: administrar acessos e estrutura organizacional dentro da plataforma.
- Segurança e compliance: gerenciar credenciais sensíveis e verificar a integridade da plataforma sem expor segredos em claro.
- Configuração da plataforma: inspecionar e ajustar a própria infraestrutura do Ansible.
Juntos, esses conjuntos cobrem os principais fluxos do dia a dia de uma equipe de operações sem que o operador precise alternar entre interfaces diferentes.
Para quem faz sentido avaliar agora
A funcionalidade ainda está em estágio de preview, o que a Red Hat chama de technology preview. Traduzindo: funciona, pode ser instalada, mas a empresa ainda está coletando experiências reais antes de recomendar para produção em larga escala. Para times que já usam Ansible no dia a dia, esse é o momento de testar com calma, em ambiente controlado, antes de virar padrão.
Quem mais tem a ganhar nessa fase inicial são equipes que hoje perdem tempo em consultas repetitivas. Aquele ciclo de abrir console, filtrar logs, confirmar status, fechar ticket. Não porque o trabalho é complexo, mas porque está disperso em várias telas e etapas. Ter um agente que responde “o que falhou ontem à noite no grupo de servidores de homologação?” com os dados reais do ambiente já justifica uma avaliação.
Para gestores de TI sem histórico técnico em Ansible, a mudança é ainda mais direta. Hoje, conseguir uma visão do estado da infraestrutura depende de alguém da equipe estar disponível para interpretar os dados. Com a integração, essa consulta vira uma pergunta em linguagem natural, e a resposta vem do ambiente real, sem intermediários.
A instalação funciona em dois cenários: empresas que rodam RHEL 9 ou 10 nos servidores, e empresas que já usam o OpenShift como plataforma de containers. Em ambos os casos, o processo segue o instalador padrão do Ansible Automation Platform, sem configurações paralelas.
O que muda no médio prazo
A tendência aqui aponta para uma redistribuição do esforço, com menos tempo em triagem e mais em decisões que exigem julgamento.
Hoje, uma parte significativa do tempo de quem opera Ansible vai para tarefas de consulta e triagem: verificar o status de um job, investigar por que um playbook falhou em dois hosts específicos, confirmar se determinado grupo de inventário está atualizado. São tarefas que não exigem julgamento complexo, mas consomem atenção.
Se um agente de IA pode responder essas perguntas diretamente — com os dados reais do ambiente, dentro das permissões definidas — o engenheiro passa a atuar onde o julgamento humano realmente importa: na decisão sobre o que automatizar, em como estruturar os playbooks, em quando não executar uma mudança.
A interface conversacional também reduz a barreira de entrada para quem não tem profundidade técnica em Ansible. Um gestor de TI que precisa entender o estado atual de um ambiente pode fazer isso sem depender de um engenheiro disponível para interpretar os dados.
Essa combinação (mais acesso para quem precisa consultar, mais foco para quem precisa executar) é onde o valor real dessa integração aparece.
Quem é a Seprol?
A Seprol é especializada em soluções tecnológicas de ponta, infraestrutura e serviços de TI, com mais de 40 anos de mercado. Hoje oferecemos muito mais do que produtos e serviços aos nossos clientes, oferecemos ferramentas inovadoras para que a sua empresa faça mais, melhor e em menos tempo, desenvolvendo todo o potencial da sua organização. Saiba mais.
A Seprol é parceira Red Hat com atuação em modernização de infraestrutura de TI. Para saber mais sobre como o Ansible Automation Platform se encaixa na estratégia de automação da sua organização, entre em contato com nossa equipe.
Leia também: Principais Pilares da Infraestrutura para a IA Corporativa
