SLA e Compliance: O que exigir do provedor

O que é SLA, Uptime e Conformidade (SOC2/GDPR)?

SLA formaliza expectativas de serviço, uptime quantifica disponibilidade e compliance como SOC 2 e GDPR comprova controles. O escopo é avaliar riscos ao contratar uma plataforma de IA; não cobre a governança interna do cliente nem obrigações setoriais específicas. Pense como um contrato de energia: há garantias, limites e consequências quando a entrega falha.

Métricas de disponibilidade costumam aparecer como percentuais mensais, por exemplo 99,9%. É essencial entender janelas de manutenção, exclusões de força maior e o que exatamente é medido, como API em produção, regiões específicas ou componentes críticos.

Tempos de resposta são descritos por latências em percentis, como P50, P95 e P99. SLOs traduzem metas internas, enquanto SLAs tornam compromissos contratuais. Verifique limites de taxa, throughput e como o provedor coleta SLIs.

Penalidades geralmente aparecem como créditos de serviço, com tetos, prazos de reivindicação e exclusões. Eles reduzem faturas futuras, mas não substituem indenizações por danos indiretos ou lucros cessantes.

SOC 2 atesta controles sobre Segurança, Disponibilidade, Confidencialidade, Integridade de Processamento e Privacidade. Avalie se o relatório é Tipo II (operacional ao longo do tempo), o período coberto e exemplos de controles como acesso e mudança.

GDPR exige base legal clara, como contrato, consentimento ou interesse legítimo, e garante direitos de acesso, apagamento, portabilidade e oposição. Para riscos elevados, procure DPIA e processos de solicitações de titulares.

Segurança deve incluir criptografia em trânsito (TLS) e em repouso, gestão de chaves, IAM com menor privilégio, MFA e registros de acesso. Confirme segregação de ambientes e proteção de segredos.

Gestão de incidentes pede critérios de severidade, prazos de notificação, definição de violação de dados e roteiro de contenção, análise de causa e ação preventiva, com comunicação transparente.

Auditoria requer evidências como relatórios SOC, resumos de testes de intrusão, política de vulnerabilidades, retenção de logs e métricas operacionais. Entenda o processo de compartilhamento sob NDA.

Residência de dados envolve escolha de regiões, restrições geográficas, subprocessadores e SCCs. O DPA precisa definir papéis de controlador/operador, finalidade, retenção e fluxos transfronteiriços.

Métricas de disponibilidade

Métricas de disponibilidade respondem à pergunta essencial: o serviço estava utilizável quando o cliente precisou? Diferentemente de latência ou throughput, elas medem a presença do serviço, não sua velocidade. Essa distinção evita confundir lentidão com indisponibilidade.

O indicador mais conhecido é o uptime, expresso em percentuais e “nines” (por exemplo, 99,9%). O contrato deve definir a janela de medição — mensal ou anual — e o que constitui “disponível”. Sem essa precisão, o mesmo número pode contar histórias muito diferentes.

A disponibilidade depende também de exclusões explícitas. Janelas de manutenção programada podem não entrar no cálculo, assim como falhas causadas por terceiros. É crucial saber se tais períodos são limitados por duração, frequência e aviso prévio.

Em arquiteturas complexas, a disponibilidade efetiva é multiplicativa: se você depende de dois serviços de 99,9%, o conjunto pode entregar menos que 99,9%. Por isso, métricas por componente e por região ajudam a entender a realidade de uma implantação multi-região ou com failover.

Muitos provedores separam plano de controle (APIs administrativas) e plano de dados (execução/serving). O SLA pode cobrir apenas o dado, enquanto o controle sofre interrupções sem penalidade. Essa distinção afeta operações de deploy e escala em momentos críticos.

Nem toda falha é total. Degradação parcial — como limites de taxa mais rígidos ou funcionalidades indisponíveis — pode não ser tratada como downtime, embora reduza a utilidade do serviço. Uma métrica complementar é o orçamento de erro, que quantifica quanto tempo de falha é “permitido” para atingir o objetivo de disponibilidade.

Indicadores operacionais como MTTR (tempo médio de reparo) e MTBF (tempo médio entre falhas) dão contexto à recuperação, mas não substituem o uptime. Eles esclarecem resiliência e previsibilidade ao longo do ciclo de incidentes.

Uma analogia útil: disponibilidade é como a porta de uma loja estar aberta; latência é a fila no caixa. Para avaliar riscos, confirme a fórmula de cálculo, as exclusões aceitas e a segmentação por região e plano, garantindo que a disponibilidade percebida pelo usuário corresponda ao número prometido no SLA.

Dúvidas frequentes — SLA, Uptime e Conformidade (SOC2/GDPR) para plataformas de IA

Que níveis de SLA devo exigir antes de migrar workloads de IA?

Peça SLAs por componente (API/serving, plano de controle, console) e por região; exija métricas claras como disponibilidade percentual (ex.: 99,9% para serviços padrão e 99,99% para criticidade alta), SLO associado e histórico de disponibilidade. Confirme janela de medição (mensal/ anual), error budget e planos de failover/replicação regional.

Como o uptime é calculado e quais exclusões devo verificar?

Exija a fórmula exata e a janela usada no cálculo; verifique exclusões comuns (manutenções programadas com aviso prévio, eventos de força maior, falhas de terceiros) e limites para janelas de manutenção. Pergunte também como são tratadas degradações parciais, que podem não contar como downtime mas impactam a utilidade do serviço.

Que tipo de compensação e processo de reivindicação devo aceitar?

Créditos de serviço são o padrão: exija teto, prazos e evidências necessárias, preferencialmente solicitação automatizada via portal e prazo definido para aplicação dos créditos. Tenha em mente que créditos raramente cobrem danos indiretos — se isso for crítico, negocie cláusulas contratuais específicas ou garantias adicionais.

Como comprovar SOC 2 e o que pedir no relatório?

Peça, preferencialmente, um relatório SOC 2 Tipo II cobrindo ao menos Segurança e Disponibilidade, com o período coberto claramente indicado. Solicite o sumário executivo e, sob NDA se necessário, acesso a evidências ou uma bridge letter; verifique controles de gestão de mudanças, controle de acesso, segregação de ambientes e resultados de testes de vulnerabilidade.

O que exigir em relação ao GDPR, DPA e residência de dados?

Exija um DPA claro que defina papéis (controlador vs operador), finalidade, períodos de retenção e lista de subprocessadores. Peça opções de residência regional e cláusulas para transferências internacionais (SCCs ou mecanismos equivalentes), além de procedimentos documentados para atender solicitações de titulares (acesso, retificação, exclusão).

Quais prazos e evidências devo definir para resposta a incidentes?

Defina níveis de severidade e prazos: notificação inicial para incidentes críticos dentro de 24 horas, atualizações regulares e relatório técnico detalhado (ex.: 30 dias) com causa raiz e ações corretivas. Exija roteiro de contenção, evidências forenses quando aplicável e relatórios de “lessons learned”; prefira provedores que realizem exercícios tabletop periódicos.

Quais controles técnicos e operacionais devo exigir para proteger dados sensíveis?

Peça TLS para trânsito e criptografia em repouso com KMS; prefira opção BYOK para chaves quando necessário. Exija IAM com princípio do menor privilégio e MFA, segregação clara entre ambientes (produção/teste), logs de auditoria imutáveis com retenção definida, evidências de testes de penetração e um programa de gestão de vulnerabilidades e patches.