IA em DevOps: usando Jev como camada de decisão em pipelines, incidentes e Kubernetes

Introdução

A adoção de Inteligência Artificial em DevOps costuma começar pelo uso de Large Language Models (LLMs) para analisar logs, explicar erros de pipeline, gerar comandos, escrever documentação ou sugerir correções.

Essa abordagem é útil, mas existe uma categoria de problema em que utilizar um LLM generativo completo pode ser desnecessário.

Considere algumas decisões comuns de uma plataforma:

• esta falha de pipeline é causada por código, infraestrutura ou dependência externa?
• o pipeline deve executar novamente?
• um incidente precisa ser escalado?
• qual equipe deve receber determinado alerta?
• este deploy apresenta risco suficiente para exigir aprovação manual?
• este log parece indicar erro de aplicação ou indisponibilidade da infraestrutura?
• devemos chamar um agente de IA mais poderoso para investigar o problema?

Essas perguntas não precisam necessariamente de uma resposta textual longa.

Elas precisam de uma decisão.

É exatamente nesse espaço que entra o Jev, modelo apresentado pela TypeSafe AI em setembro de 2026. Diferentemente de um LLM tradicional, o Jev foi projetado para receber um estado, executar perguntas delimitadas e retornar decisões estruturadas com probabilidades e confiança. A TypeSafe classifica essa arquitetura como um modelo System One, voltado a decisões rápidas dentro de software.

Para DevOps, SRE e Platform Engineering, isso abre uma arquitetura interessante:

Pipeline / Kubernetes / Observabilidade
                 ↓
          coleta de contexto
                 ↓
                Jev
                 ↓
      decisão estruturada
                 ↓
      ┌──────────┼──────────┐
      ↓          ↓          ↓
    retry     escalar     ignorar
                            ↓
                          ação

O ponto principal é que o Jev não substitui Kubernetes, Azure DevOps, Prometheus ou um LLM.

Ele pode funcionar como uma camada de decisão entre eventos técnicos e automações.

O que é Jev?

Jev é o primeiro modelo público da TypeSafe AI baseado no conceito de System One Models.

Em vez de receber uma pergunta e produzir texto token por token, como normalmente acontece com um LLM generativo, o modelo trabalha com um conjunto limitado de possíveis respostas.

O contrato conceitual é:

STATE + QUESTIONS
        ↓
       JEV
        ↓
DECISÕES + PROBABILIDADES

Um estado poderia ser:

Pipeline: payments-api
Stage: Build
ExitCode: 137

Logs:
Killed
npm ERR! process terminated
Node worker exited unexpectedly

E a aplicação poderia perguntar:

Qual a provável categoria da falha?

- application
- infrastructure
- dependency
- timeout
- resource
- unknown

Em vez de produzir:

Parece que seu processo provavelmente foi encerrado por falta de memória...

a aplicação recebe algo conceitualmente semelhante a:

{
  "category": "resource",
  "probability": 0.94
}

O software pode então decidir:

if probability >= 0.90 and category == "resource":
    retry_pipeline()

Esse modelo é especialmente adequado para automação porque reduz a dependência de parsing de texto livre e restringe as possíveis respostas ao espaço de decisões definido pela aplicação. A própria TypeSafe descreve Jev como uma espécie de chamada de função inteligente: estado não estruturado entra e decisões probabilísticas tipadas saem.

System One versus LLM tradicional

Uma maneira simples de visualizar a diferença é:

Portanto, uma arquitetura eficiente pode combinar ambos.

Evento
  ↓
Jev
  ↓
classificação
  ↓
problema simples?
 ├─ sim → automação
 │
 └─ não
      ↓
     LLM
      ↓
 investigação detalhada

Isso cria uma espécie de AI Cascade.

O modelo mais barato e especializado resolve decisões simples.

Modelos maiores ficam reservados para situações que realmente precisam de análise complexa.

Principais conceitos

State

O state representa o contexto que será analisado.

Em DevOps pode incluir:

pipeline name
stage
exit code
logs
duration
commit
environment
deployment status
pod status
events Kubernetes
metrics

Exemplo:

{
  "pipeline": "checkout-api",
  "stage": "deploy",
  "exitCode": 1,
  "environment": "production",
  "logs": "ImagePullBackOff..."
}

A qualidade do state influencia diretamente a qualidade da decisão.

Não adianta enviar milhares de linhas irrelevantes.

Uma camada anterior deve preferencialmente normalizar os dados.

Choice

Choice representa uma escolha entre opções conhecidas.

Exemplo:

Qual é a provável causa?

application
infrastructure
dependency
security
resource
unknown

É particularmente útil para classificação.

Score

Score permite avaliar algo dentro de uma escala.

Por exemplo:

Risco do deployment:

1 - muito baixo
2 - baixo
3 - médio
4 - alto
5 - crítico

Isso pode alimentar um deployment gate.

Noul

Outro tipo de pergunta é uma decisão aproximadamente equivalente a sim/não acompanhada de probabilidade.

Por exemplo:

Essa falha provavelmente será resolvida por um retry?

Resultado conceitual:

true: 0.91
false: 0.09

Choice, Score e Noul estão entre os tipos centrais de perguntas documentados no ecossistema do Jev.

Arquitetura de IA em DevOps usando Jev

Um ambiente real poderia utilizar a seguinte arquitetura:

Azure DevOps
     │
     │ logs / status
     ▼
Classifier Service
     │
     ▼
Jev API
     │
     ▼
Decision Engine
     │
 ┌───┼────────────┐
 │   │            │
 ▼   ▼            ▼
Retry Escalate   Ignore
 │   │
 │   └───────────────► Teams / PagerDuty / Jira
 │
 ▼
Azure DevOps API

Em Kubernetes:

EKS
 │
 ├── API
 ├── Workers
 ├── RabbitMQ
 └── PostgreSQL
       │
       ▼
Prometheus / Loki
       │
       ▼
Incident Collector
       │
       ▼
Jev
       │
       ▼
Decision Engine
       │
       ├── retry
       ├── restart
       ├── alert
       └── LLM Investigator

O Jev não executa necessariamente a ação.

Ele ajuda a responder:

O que o sistema deveria fazer?

A ação continua sob responsabilidade da aplicação.

Essa separação é importante para segurança.

Exemplo do dia a dia: classificar falhas de build

Imagine uma organização com dezenas de microsserviços.

Todos os dias aproximadamente 600 pipelines executam no Azure DevOps.

Um pipeline falha com:

##[error]The process '/usr/bin/docker' failed with exit code 1
error pulling image configuration:
download failed after attempts=6
TLS handshake timeout

Normalmente um desenvolvedor abre o log e tenta entender:

Código?
Docker?
Registry?
Network?
Agent?

Um serviço poderia coletar:

{
  "pipeline": "customer-api",
  "stage": "docker-build",
  "exit_code": 1,
  "message": "TLS handshake timeout pulling base image"
}

E perguntar:

Classifique a causa mais provável:

application
network
registry
dependency
agent
unknown

Resultado hipotético:

registry: 0.72
network: 0.23
unknown: 0.05

O pipeline poderia aplicar:

confidence >= 0.90 → retry automático

0.70 até 0.89 → registrar classificação

< 0.70 → investigação manual

Esse detalhe é fundamental.

Probabilidade não deve ser confundida com certeza.

A própria documentação do ecossistema ressalta que confiança deve orientar o workflow, e não ser interpretada como garantia de correção.

Exemplo de integração HTTP

Uma integração básica pode chamar diretamente a API.

Uma estrutura simplificada seria:

curl -X POST \
  "https://api.typesafe.ai/v1/systemone" \
  -H "Authorization: Bearer ${TYPESAFE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": {
      "pipeline": "payments-api",
      "stage": "build",
      "exitCode": 137,
      "logs": "Process terminated unexpectedly after memory usage increased."
    },
    "questions": {
      "failure_type": {
        "type": "choice",
        "instructions": "Classify the most likely cause of this pipeline failure.",
        "options": [
          "application",
          "dependency",
          "infrastructure",
          "resource",
          "timeout",
          "unknown"
        ]
      }
    }
  }'

O endpoint POST /v1/systemone e o uso de state acompanhado de perguntas tipadas fazem parte do contrato documentado para o modelo.

Os nomes das categorias não vêm do Jev.

Quem define o espaço de decisão é a aplicação.

Esse detalhe permite modelar taxonomias específicas da empresa.

Classificador para Azure DevOps

Podemos criar um pequeno serviço responsável pela classificação.

Fluxo:

Azure DevOps
     ↓
log do pipeline
     ↓
failure-classifier
     ↓
Jev
     ↓
classification
     ↓
pipeline decision

Uma aplicação Python poderia seguir a seguinte lógica:

import os
import requests

API_URL = "https://api.typesafe.ai/v1/systemone"
API_KEY = os.environ["TYPESAFE_API_KEY"]


def classify_failure(log: str) -> dict:
    payload = {
        "model": "jev-latest",
        "state": {
            "log": log
        },
        "questions": {
            "failure_type": {
                "type": "choice",
                "instructions": (
                    "Classify the primary cause of this CI/CD failure."
                ),
                "options": [
                    "application",
                    "dependency",
                    "network",
                    "infrastructure",
                    "resource",
                    "timeout",
                    "unknown"
                ]
            }
        }
    }

    response = requests.post(
        API_URL,
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=10,
    )

    response.raise_for_status()

    return response.json()

Em produção ainda seriam necessários:

• retry com backoff;
• tratamento de timeout;
• circuit breaker;
• telemetry;
• redaction de secrets;
• rate limiting;
• controle de tamanho do state.

Azure DevOps Pipeline

Um pipeline poderia executar a classificação apenas após uma falha.

Exemplo conceitual:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: ubuntu-latest

stages:
  - stage: Build
    jobs:
      - job: BuildApplication

        steps:
          - script: |
              npm ci
              npm run build
            displayName: Build application

          - script: |
              python scripts/classify_failure.py \
                "$(System.DefaultWorkingDirectory)/pipeline.log"
            condition: failed()
            displayName: Classify failure with Jev
            env:
              TYPESAFE_API_KEY: $(TYPESAFE_API_KEY)

O segredo deve estar armazenado como secret variable, variable group protegido ou outra solução de secret management.

Nunca:

TYPESAFE_API_KEY: abc123

diretamente no repositório.

Usando Jev com Kubernetes

Outra aplicação interessante é classificação de incidentes Kubernetes.

Considere:

Pod → CrashLoopBackOff

O sistema coleta:

kubectl describe pod
kubectl logs
kubectl get events

Depois monta o contexto:

{
  "pod": "checkout-api-76d88f",
  "namespace": "production",
  "status": "CrashLoopBackOff",
  "restartCount": 14,
  "logs": "connection refused postgres:5432"
}

O Jev pode classificar:

application
database
network
configuration
resource
unknown

Nesse exemplo provavelmente:

database

A automação pode então decidir qual runbook executar.

YAML Kubernetes

Um serviço responsável por classificar eventos poderia ser implantado no cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jev-incident-classifier
  namespace: platform
spec:
  replicas: 2

  selector:
    matchLabels:
      app: jev-incident-classifier

  template:
    metadata:
      labels:
        app: jev-incident-classifier

    spec:
      serviceAccountName: jev-classifier

      containers:
        - name: classifier
          image: registry.example.com/platform/jev-classifier:1.0.0

          ports:
            - containerPort: 8080

          env:
            - name: TYPESAFE_API_KEY
              valueFrom:
                secretKeyRef:
                  name: jev-api
                  key: api-key

          resources:
            requests:
              cpu: 100m
              memory: 128Mi

            limits:
              cpu: 500m
              memory: 512Mi

          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

            initialDelaySeconds: 5
            periodSeconds: 10

          livenessProbe:
            httpGet:
              path: /health
              port: 8080

            initialDelaySeconds: 15
            periodSeconds: 20

---
apiVersion: v1
kind: Service
metadata:
  name: jev-incident-classifier
  namespace: platform
spec:
  selector:
    app: jev-incident-classifier

  ports:
    - port: 80
      targetPort: 8080

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jev-classifier
  namespace: platform

O que essa configuração faz?

Cria duas réplicas do serviço de classificação.

O serviço recebe eventos, prepara o contexto e consulta o Jev.

replicas: 2 evita depender de uma única instância.

Os requests garantem recursos mínimos:

cpu: 100m
memory: 128Mi

Enquanto os limits impedem crescimento descontrolado.

As probes permitem que Kubernetes retire containers não saudáveis do tráfego.

Em produção seria recomendado complementar com:

• PodDisruptionBudget;
• NetworkPolicy;
• HorizontalPodAutoscaler;
• observabilidade;
• External Secrets;
• IAM específico;
• políticas de egress.

Segurança

Integrar IA com infraestrutura exige cuidado.

O maior erro seria transformar:

Jev → execução direta

em:

Jev decidiu restart → kubectl delete pod

sem controles intermediários.

Uma arquitetura mais segura seria:

Jev
 ↓
Decision Engine
 ↓
Policy Engine
 ↓
Risk Check
 ↓
Action

Por exemplo:

if (
    decision == "restart"
    and confidence >= 0.95
    and environment != "production"
):
    restart()

Para produção:

restart recomendado
       ↓
policy
       ↓
aprovação / runbook

Princípio do menor privilégio

O classificador não precisa ter:

cluster-admin

Na maioria dos casos ele nem precisa alterar recursos.

Seu RBAC pode ser somente leitura:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: incident-reader
  namespace: production
rules:
  - apiGroups:
      - ""

    resources:
      - pods
      - events

    verbs:
      - get
      - list

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: incident-reader-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: jev-classifier
    namespace: platform

roleRef:
  kind: Role
  name: incident-reader
  apiGroup: rbac.authorization.k8s.io

Caso decisões resultem em ações, um serviço separado pode possuir permissões específicas.

Redação e vazamento de segredos

Logs podem conter:

Authorization: Bearer ...
password=
AWS_SECRET_ACCESS_KEY=
connectionString=

Nunca envie logs diretamente para qualquer serviço externo sem sanitização.

Antes:

raw logs
   ↓
secret redaction
   ↓
normalização
   ↓
Jev

Uma expressão simples poderia remover padrões conhecidos.

Porém em produção a sanitização deve considerar:

• tokens JWT;
• credentials AWS;
• headers HTTP;
• connection strings;
• cookies;
• informações pessoais;
• dados regulados.

Exemplo em produção

Considere um EKS com:

120 microsserviços
600 pipelines/dia
4.000 pods
Prometheus
Grafana
Loki
Tempo
Alertmanager
RabbitMQ
PostgreSQL
Redis

Todos os dias centenas de alertas podem surgir.

Em vez de enviar todos diretamente para o PagerDuty:

Prometheus
   ↓
Alertmanager
   ↓
PagerDuty

poderíamos adicionar uma camada:

Prometheus
   ↓
Alertmanager
   ↓
Incident Processor
   ↓
Jev
   ↓
severity / team / action
   ↓
Routing Engine
   ↓
PagerDuty / Slack / Jira

Por exemplo:

CPU 95%
pod restarts = 0
latency normal
duration = 2 min

Classificação:

severity=low

Outro evento:

HTTP 5xx = 72%
checkout unavailable
3 replicas down
database latency 8s

Classificação:

severity=critical
team=platform
requires_human=true

O sistema então cria o incidente.

Jev + LLM

Uma das arquiteturas mais interessantes é combinar os dois.

Incident
   ↓
Jev
   ↓
simple?
 │
 ├─ YES
 │    ↓
 │ runbook
 │
 └─ NO
      ↓
   GPT / Claude / outro LLM
      ↓
 investigação

O Jev funciona como um router inteligente.

O LLM continua responsável pelo raciocínio complexo.

Essa combinação evita utilizar modelos mais caros para tarefas que são essencialmente classificação.

Projetos da comunidade já experimentam Jev justamente nessa posição intermediária, realizando classificação antes de encaminhar contexto para agentes maiores.

Observabilidade

Uma solução dessas precisa ser observável.

Não basta saber:

Jev respondeu resource

É necessário registrar:

request_id
pipeline
decision
confidence
duration
action
model_version
timestamp

Exemplo de métrica Prometheus:

jev_requests_total
jev_request_duration_seconds
jev_decision_total
jev_low_confidence_total
jev_errors_total

Exemplo:

jev_decision_total{
  decision="resource",
  pipeline="payments"
} 143

No Grafana poderia existir:

Decisões/minuto

Confiança média

Top categorias

Low confidence %

Erro de API

Latência p95

Automated actions

Manual escalations

Logs

Um log estruturado adequado seria:

{
  "timestamp": "2026-09-27T10:00:00Z",
  "pipeline": "payments-api",
  "classification": "resource",
  "confidence": 0.94,
  "action": "retry",
  "duration_ms": 182
}

No Loki:

{app="jev-classifier"}
| json
| classification="resource"

Tracing

OpenTelemetry pode acompanhar:

pipeline-event
     ↓
classifier
     ↓
Jev API
     ↓
decision-engine
     ↓
Azure DevOps API

Isso permite descobrir se um problema está:

no coletor
na rede
na API
na decisão
na automação

Troubleshooting

API retornando timeout

Verifique conectividade:

curl -I https://api.typesafe.ai

Dentro do Kubernetes:

kubectl exec -n platform \
  deploy/jev-incident-classifier \
  -- curl -I https://api.typesafe.ai

Possíveis causas:

DNS
NetworkPolicy
proxy
firewall
egress bloqueado
falha externa

Pod do classificador reiniciando

kubectl get pods -n platform

kubectl describe pod \
  -n platform \
  <pod>

kubectl logs \
  -n platform \
  <pod>

Eventos:

kubectl get events \
  -n platform \
  --sort-by=.metadata.creationTimestamp

Verifique:

OOMKilled
CrashLoopBackOff
ImagePullBackOff
probes
secret ausente

Secret não encontrado

kubectl get secret jev-api \
  -n platform

Não imprima o valor do segredo em pipelines ou logs.

Classificações ruins

Nem todo problema é infraestrutura.

O primeiro ponto a investigar deve ser o state.

Por exemplo:

STATE RUIM

"pipeline failed"

versus:

STATE MELHOR

pipeline=payments-api
stage=deploy
exit_code=137
pod_status=OOMKilled
memory_limit=512Mi
memory_peak=510Mi

IA não substitui qualidade de contexto.

Desenvolvimento versus produção

Desenvolvimento

Pode ser aceitável:

uma réplica
logs completos
threshold menor
ações simuladas
sem autoscaling

Exemplo:

confidence > 0.70 → mostrar recomendação

Produção

Deve existir:

redundância
timeouts
retry
circuit breaker
rate limiting
redaction
observabilidade
versionamento
auditoria
thresholds maiores
controle de ações

Por exemplo:

confidence >= 0.95 → ação automática segura

0.80-0.94 → sugestão

<0.80 → investigação manual

Os thresholds precisam ser calibrados com dados reais.

Boas práticas

Comece com decisões pequenas

Não comece perguntando:

Resolva qualquer incidente da minha infraestrutura.

Comece com:

Classifique esta falha.

Depois:

Determine se retry provavelmente resolverá.

Depois:

Determine qual runbook utilizar.

Automação madura é construída progressivamente.

Mantenha o espaço de decisão limitado

Prefira:

resource
application
network
dependency
unknown

a dezenas de categorias quase idênticas.

Tenha uma opção unknown

Forçar uma decisão pode gerar automações ruins.

Sempre que possível:

unknown

deve ser um resultado válido.

Utilize confidence gates

Nunca trate:

0.51

como equivalente a:

0.99

Registre todas as decisões

Para auditoria:

input
model
decision
confidence
action
resultado

O que evitar

Evite arquiteturas do tipo:

Alert
 ↓
IA
 ↓
kubectl delete

Também evite:

IA com cluster-admin

ou:

logs não filtrados contendo secrets

Outro erro comum é usar IA onde uma regra simples resolveria.

Por exemplo:

if exit_code == 0:
    return "success"

não precisa de IA.

Custos e FinOps

O custo real de uma arquitetura com IA não vem apenas da chamada ao modelo.

Considere:

tokens
API requests
serviço intermediário
observabilidade
storage
rede
LLMs secundários

A TypeSafe atualmente publica um preço de US$ 42 por bilhão de tokens de entrada, equivalente a aproximadamente US$ 0,042 por milhão de tokens, posicionando Jev como uma camada de decisão de baixo custo em comparação com diversos modelos generativos.

Isso pode ser relevante quando existem milhares ou milhões de pequenas decisões.

Considere:

100.000 eventos/dia

Se todos fossem enviados a um LLM grande:

100.000
   ↓
LLM

a arquitetura poderia ser substituída por:

100.000
   ↓
regras simples
   ↓
Jev
   ↓
apenas 2.000 complexos
   ↓
LLM

Essa estratégia reduz:

tokens
latência
custo
dependência de modelos maiores

Kubernetes e custo

O próprio serviço de classificação tende a ser leve.

Por exemplo:

requests:
  cpu: 100m
  memory: 128Mi

Portanto pode rodar em nós Spot quando apropriado.

Mas o serviço de classificação não deve ser colocado em Spot sem considerar disponibilidade.

Uma abordagem poderia ser:

2 replicas

com distribuição entre nós.

O custo de computação local provavelmente será pequeno comparado a pipelines, observabilidade e workloads principais.

Quando utilizar Jev

Jev faz sentido quando existem decisões frequentes e delimitadas.

Exemplos:

classificação de pipelines

triagem de incidentes

alert routing

ticket routing

deployment risk scoring

agent routing

seleção de ferramentas

priorização

classificação de logs

confidence gates

decisão de retry

Quando não utilizar

Não utilize Jev para problemas como:

"Explique por que meu Kubernetes está lento."

"Escreva meu Terraform."

"Crie uma arquitetura completa."

"Resuma estes 500 logs."

"Corrija meu código."

Esses problemas exigem geração ou raciocínio aberto.

Um LLM tradicional é mais adequado.

Também não utilize IA quando uma regra determinística resolver.

if pod.status == "Succeeded":
    return

é melhor que qualquer modelo.

Arquitetura recomendada

Uma estratégia madura de IA em DevOps poderia ter quatro camadas:

                 EVENTS

                   ↓

          DETERMINISTIC RULES

                   ↓

                  JEV

                   ↓

            COMPLEX CASE?

            ┌──────┴──────┐
            │             │
           NO            YES
            │             │
            ▼             ▼

         RUNBOOK          LLM
                            │
                            ▼
                       HUMAN REVIEW

Essa arquitetura evita dois extremos.

O primeiro:

não usar IA para nada

O segundo:

usar LLM para absolutamente tudo

O melhor desenho tende a combinar:

código determinístico
+
modelos rápidos de decisão
+
LLMs
+
automação
+
human-in-the-loop

Resumo prático

Jev não deve ser entendido como um substituto direto de ChatGPT, Claude ou outros modelos generativos.

Seu papel é diferente.

LLM
→ gera

Jev
→ decide

Em DevOps isso permite criar uma camada inteligente entre eventos e automações.

Um pipeline pode utilizar Jev para determinar:

tipo de falha
risco
necessidade de retry
necessidade de escalonamento

Um cluster Kubernetes pode utilizá-lo para:

classificação de incidentes
routing de alertas
seleção de runbooks
priorização

E sistemas de agentes podem utilizá-lo para decidir:

qual ferramenta chamar
qual modelo utilizar
quando escalar
quando parar

Tudo isso deve ser acompanhado por:

confidence thresholds
RBAC
auditoria
observabilidade
sanitização
policy engines
human-in-the-loop

Conclusão

Durante muitos anos, a associação entre Inteligência Artificial e DevOps esteve concentrada em ferramentas capazes de gerar texto: explicar logs, escrever YAML, criar scripts ou auxiliar durante incidentes.

O surgimento de modelos orientados a decisões permite explorar uma camada diferente.

Nem todo problema precisa de um modelo que escreva cinco parágrafos.

Às vezes o sistema precisa apenas responder:

Qual categoria?

Qual prioridade?

Qual ação?

Retry ou não?

Escalar ou não?

Qual ferramenta?

Qual agente?

É nesse ponto que uma tecnologia como Jev se torna particularmente interessante.

Em uma plataforma moderna, podemos imaginar:

Azure DevOps
Kubernetes
Prometheus
Loki
OpenTelemetry
Alertmanager
       │
       ▼
   Event Layer
       │
       ▼
     Jev
       │
       ▼
 Decision Engine
       │
       ├── automação
       ├── runbook
       ├── LLM
       └── humano

O resultado não é simplesmente "colocar IA no pipeline".

É criar uma camada inteligente de decisão dentro da plataforma.

Para DevOps, SRE e Platform Engineering, essa diferença é importante.

O objetivo deixa de ser apenas utilizar IA para responder perguntas e passa a ser utilizar IA para ajudar sistemas a tomarem pequenas decisões operacionais com velocidade, estrutura, observabilidade e limites claros.

Quando combinado com código determinístico, políticas, telemetria, runbooks, LLMs e controles humanos, o Jev pode ocupar exatamente essa posição: a camada de decisão rápida entre o que aconteceu na infraestrutura e o que a plataforma deve fazer em seguida.