Fonte: SDRs/sdr-0007-ans-parametros-sla.md

SDR — ANS: parametros, SLA e medicao

Eixo: Arquitetura Contratual (Modelo de Servicos | Arquitetura Contratual | Ambos)

Campo	Valor
SSoT	Sim — dono das regras estruturais para agentes criarem e manterem o ANS
Estado	âncora; modelo atual em `arquitetura-contratual/ANS-Acordo-de-Niveis-de-Servico-modelo.md`

1. Finalidade

O ANS operacionaliza o que sera medido, quando sera medido, quais metas se aplicam e como o resultado afeta pagamento, glosa, ARRC e plano de saneamento.

2. Conteudo minimo

periodo de medicao e faturamento;
congelamento da base remuneravel;
unidades U1-U7 e vinculo com IMR;
SLAs por criticidade, servico e categoria de ativo;
prazos de publicacao de evidencias;
criticidade, persistencia e reincidencia;
estados de conformidade e percentuais;
regras de glosa por nexo;
ARRC e tolerancia;
processo de disputa e decisao pela Administracao;
relatorios e paineis obrigatorios.

3. Regras canônicas

O ANS deve transformar conceitos em codigos mensuraveis: tipo de falha, criticidade, prazo, responsavel, evidencia e efeito financeiro.
Toda meta deve ter fonte de evidencia e canal oficial.
O ANS deve impedir efeito punitivo duplo pelo mesmo fato.
A trava trilateral deve ficar restrita a gatilhos objetivos, conforme SDR trava/glosa.
Outros deve ter teto, saldo, catalogo, OS, aceite e vedacoes.

4. Regras para agentes

Sempre produzir tabelas operacionais, nao apenas texto conceitual.
Separar meta de atendimento, meta de disponibilidade, meta de evidencia, meta de seguranca e meta de continuidade.
Quando o numero depender do orgao, usar placeholder com orientacao de preenchimento.
Nao deixar "conforme" depender de avaliacao subjetiva sem checklist.

5. Consumidores

Entregavel	Como usa este SDR
ANS	estrutura completa
TR	anexo de medicao e pagamento
Gestao contratual	rotina mensal de medicao
Site	paginas de governanca, IMR e aspectos comuns

6. Protocolo de entrega de evidências para análise pela IA

Este protocolo complementa o conteúdo mínimo do ANS (seção 2) com as exigências específicas para que a camada de IA da APF possa analisar as evidências entregues por C1, C2 e C3. A política completa de uso de IA está em sdr-0026-ia-apoio-modelo-servico.md.

6.1 Canais e formatos aceitos

O ANS deve especificar, por domínio e por unidade IMR, o canal oficial de entrega de evidências e os formatos aceitos pelo sistema de análise da APF. A IA processa apenas evidências entregues nos canais pactuados; evidência entregue fora do canal não é considerada para efeito de análise automática.

Domínio	Canal	Formato mínimo aceito
C1 — ITSM / chamados	API ITSM ou exportação estruturada no canal pactuado	JSON ou CSV com campos obrigatórios definidos no ANS
C1 — CMDB	Exportação CMDB no canal pactuado	JSON ou CSV com campos de CI, localidade, categoria e data de atualização
C1 — Painel mensal	Publicação no canal pactuado até D+X	Formato definido no ANS; campos obrigatórios por unidade IMR
C2 — Relatório de postos	Canal pactuado	Planilha ou JSON com: localidade, quantidade de postos, categoria N1/N2/N3
C3 — SIEM / triagem SOC	Canal pactuado (API SIEM ou exportação estruturada)	JSON estruturado com: ID do alerta, classificação L1/L2, timestamp, playbook aplicado, SLA de reconhecimento
C3 — Scan de vulnerabilidades	Canal pactuado	JSON ou CSV com: ativo (CI), CVE, CVSS, status (aberta/corrigida), data de detecção, data de patch
C3 — Evidência de DR/restore	ITSM — canal pactuado	Registro de chamado com: ativo testado, data do teste, resultado, RTO/RPO atingido
C3 — Ciclo JML (IAM)	ITSM — canal pactuado	Registros com: usuário, tipo de evento (joiner/mover/leaver), data e evidência de provisionamento/desprovisionamento

6.2 Prazos de entrega por domínio

O ANS deve fixar os prazos de entrega de evidências para cada domínio. Os prazos devem ter margem suficiente antes do fechamento do ciclo de medição para permitir que as empresas corrijam entregas atrasadas ou em formato incorreto.

Domínio	Prazo de entrega	Prazo máximo de correção de entrega com erro
C1 — Painel mensal	D+X após fechamento do período (X definido no ANS)	D+X+2 (dois dias úteis após o prazo)
C1 — CMDB	Congelamento mensal conforme cronograma ANS	D+2 após notificação de inconsistência
C2 — Relatório de postos	D+3 após fechamento do período	D+5 após notificação
C3 — Evidências SOC (ciclo mensal)	D+3 após fechamento do período	D+5 após notificação
C3 — Relatório de vulnerabilidades	D+3 após fechamento do período	D+5 após notificação
C3 — Evidências DR/restore	Até 5 dias úteis após a realização do teste	D+3 após notificação

6.3 Consequências da ausência ou atraso de entrega

A IA sinaliza a ausência de entrega como lacuna declarada — não infere nem supõe o que não foi entregue.
Evidência entregue fora do prazo sem justificativa: registrada como [ENTREGA FORA DO PRAZO] na análise, com impacto no IQD e na completude do ciclo.
Evidência em formato não reconhecido: sinalizada como [FORMATO NÃO PROCESSÁVEL] — nunca ignorada silenciosamente. A empresa tem prazo de correção conforme tabela acima.
Ausência de entrega no prazo de correção: registrada no ITSM como ponto cego declarado na análise mensal, com impacto na avaliação de completude de C1 (quando aplicável) ou na análise de conformidade de C2/C3.
A ausência de entrega não isenta a empresa da obrigação contratual — a IA apenas documenta a lacuna para fins de medição pelo C1 e fiscalização pela APF.

6.4 Camada de verificação de integridade de fonte

Antes de qualquer análise de conteúdo, a IA verifica automaticamente:

Canal: a evidência chegou pelo canal pactuado no ANS?
Formato: a estrutura segue o esquema acordado (campos obrigatórios presentes, tipos corretos)?
Prazo: a entrega respeitou o prazo do protocolo?
Completude formal: todas as unidades IMR estão cobertas? Existe registro para cada ativo crítico da CMDB?
Consistência cruzável: onde dois sistemas deveriam concordar (ex.: ITSM e painel), há divergência acima do limiar parametrizado?

Dado não cruzável entre fontes independentes recebe tag [FONTE NÃO CRUZÁVEL — REVISÃO HUMANA OBRIGATÓRIA] em toda saída analítica que o utilize. A verificação de integridade formal não é auditoria forense — a empresa que entregou a evidência responde pela sua veracidade.

6.5 Integração técnica exigida

O ANS deve exigir de C1, C2 e C3 a disponibilização de:

API de acesso ao ITSM com autenticação controlada pela APF, para leitura de chamados, registros de mudança e evidências;
Exportação periódica do CMDB em formato estruturado no canal pactuado;
API ou exportação do SIEM (C3) com registros de alertas e triagem;
Acesso de leitura ao scanner de vulnerabilidades (C3) ou exportação estruturada dos relatórios.

Se o sistema não tiver API acessível ou exportação padronizada, o ANS deve especificar o processo manual equivalente e os prazos correspondentes. A ausência de integração técnica não dispensa a obrigação de entrega — apenas define o formato alternativo aceito.

Ligacoes

Agentes de conformidade (Cursor)

Os três agentes abaixo aplicam-se à edição e à revisão dos arquivos SDRs/sdr-*.md (exceto SDRs/templates/ e normas em SDRs/governance/). Este bloco é informativo; use o script na raiz do repositório para diagnóstico estrutural.

Agente	Regra Cursor	Norma em `SDRs/governance/rules/`
Verificador de conformidade SDR	`sdr-conformity-checker.mdc`	`sdr-conformity-checker.md`
Detector de implementação sem vínculo SDR	`implementation-without-sdr-detector.mdc`	`implementation-without-sdr-detector.md`
Anti-vibecoding sem SDR	`no-vibecoding-without-sdr.mdc`	`no-vibecoding-without-sdr.md`

Processo: governance/README.md · Rastreabilidade código: traceability.md · Checagem: python scripts/check_sdr_conformity.py (na raiz do repositório).