Avaliação de prontidão para ISO 42001 e SOC 2

Mapeia a implementação de referência ai-agent-eval-harness-healthtech frente à ISO/IEC 42001:2023 (Sistema de Gestão de IA) e aos Critérios de Serviços de Confiança do SOC 2. Esta é uma avaliação honesta de prontidão: o sistema é uma implementação de referência e não foi auditado frente a nenhum dos dois padrões. A avaliação examina quais controles existem, quais estão parcialmente abordados e o que um processo formal de certificação exigiria.

Leia em conjunto com o mapeamento do NIST AI RMF e o plano de registro de auditoria.

ISO/IEC 42001:2023 — Sistema de Gestão de IA

A ISO 42001 é o primeiro padrão internacional para sistemas de gestão de IA. Ela fornece um arcabouço para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de IA dentro de uma organização. O padrão segue a estrutura harmonizada dos padrões de sistemas de gestão da ISO (Plan-Do-Check-Act).

Mapeamento cláusula por cláusula

Cláusula 4: Contexto da organização

Requisito	Implementação atual	Lacuna
4.1 Entendimento da organização e de seu contexto	O escopo do repositório (implementação de referência), os invariantes e as partes interessadas pretendidas (engenheiros, revisores de governança) são descritos na visão geral do repositório e no processo de divulgação de segurança	O contexto cobre o repositório; um SGSI formal precisaria do contexto organizacional, incluindo estratégia de negócios, mercado e cenário regulatório
4.2 Entendimento das necessidades e expectativas das partes interessadas	Usuários pretendidos definidos no cartão do modelo: engenheiros, revisores de governança; postura regulatória definida na postura regulatória	Sem análise formal das partes interessadas; o projeto de autor único tem diversidade limitada de partes interessadas
4.3 Determinação do escopo do sistema de gestão de IA	Escopo definido na especificação do sistema e na postura regulatória: coach de bem-estar para adesão à medicação, voltado ao paciente, sem funções clínicas	O escopo é em nível de repositório; o escopo de um SGSI cobriria todo o ciclo de vida da IA dentro da organização
4.4 Sistema de gestão de IA	O arcabouço de avaliação como sistema de medição; os registros de decisões de arquitetura como registros de decisão; as salvaguardas como controles; o OpenTelemetry como monitoramento; a postura regulatória como política	Demonstra o padrão; não é um sistema de gestão formal com procedimentos, responsabilidades e ciclos de revisão definidos

Cláusula 5: Liderança

Requisito	Implementação atual	Lacuna
5.1 Liderança e comprometimento	Comprometimento do autor com a governança demonstrado por um amplo conjunto de documentos de governança e registros de decisões de arquitetura, pelo arcabouço de avaliação e por declarações honestas de limitações	Autor único; sem estrutura de comprometimento da alta direção; sem processo de alocação de recursos
5.2 Política	A postura regulatória serve como a política regulatória; o registro de decisão operacional captura as políticas operacionais	Sem documento formal de política de IA; as políticas estão distribuídas por vários artefatos
5.3 Papéis, responsabilidades e autoridades organizacionais	Propriedade dos módulos documentada (salvaguardas, avaliações, observabilidade); propriedade dos registros de decisão por decisão	Sem definições formais de papéis; sem delegação de autoridade; sem segregação de funções

Cláusula 6: Planejamento

Requisito	Implementação atual	Lacuna
6.1 Ações para abordar riscos e oportunidades	O modelo de ameaças OWASP / ATLAS mapeia ameaças; o mapeamento do NIST AI RMF mapeia funções de risco; o arcabouço de avaliação detecta regressões; o red-team noturno submete os riscos a testes adversariais	Sem registro formal de riscos; sem plano de tratamento de riscos; sem registro de oportunidades
6.2 Objetivos de IA e planejamento para alcançá-los	A especificação do sistema define objetivos; os limiares de avaliação definem metas mensuráveis; o histórico de versões é publicado	Os objetivos são em nível de repositório; sem objetivos de IA organizacionais nem planos de recursos
6.3 Avaliação de riscos de IA	Modelo de ameaças (OWASP/ATLAS), mapeamento do NIST AI RMF, declarações honestas de limitações no cartão do modelo	A avaliação é qualitativa e documentada; sem pontuação quantitativa de risco; sem aceitação de risco residual

Cláusula 7: Apoio

Requisito	Implementação atual	Lacuna
7.1 Recursos	Meta de custo de US$ 0/mês; infraestrutura de nível gratuito; ferramentas existentes (pytest, OpenTelemetry, Promptfoo)	Sem processo de planejamento de recursos; sem alocação de orçamento; sem gestão de capacidade
7.2 Competência	O autor demonstra competência no domínio por meio de decisões arquiteturais, mapeamento regulatório e documentação de governança	Sem arcabouço de competências; sem registros de treinamento; sem processo de avaliação de competências
7.3 Conscientização	O controle de alterações da postura regulatória exige um registro de decisão para mudanças de escopo; o processo de divulgação de segurança	Sem programa formal de conscientização; sem métricas de conscientização
7.4 Comunicação	Documentos de governança públicos; o cartão do modelo; a postura regulatória; os registros de decisões de arquitetura	A comunicação é passiva (documentos publicados); sem plano ativo de comunicação com as partes interessadas
7.5 Informação documentada	Os registros de decisões de arquitetura, os documentos de governança, a especificação do sistema, a postura regulatória, a declaração de dados, o cartão do modelo	A documentação é abrangente; com versionamento controlado; sem sistema formal de gestão de documentos

Cláusula 8: Operação

Requisito	Implementação atual	Lacuna
8.1 Planejamento e controle operacional	O arcabouço de avaliação valida cada alteração; as salvaguardas impõem o escopo; o OpenTelemetry monitora a execução; orçamentos de custo/latência impostos	Os controles operacionais existem; sem plano operacional formal; sem processo de gestão de mudanças
8.2 Avaliação de riscos de IA (operacional)	O classificador de escopo roda em cada entrada; a detecção de escalonamento roda em cada entrada; a redação de PII roda em cada entrada/saída	Avaliação de risco em tempo real para funções críticas de segurança; sem avaliação operacional de risco mais ampla
8.3 Tratamento de riscos de IA	Arquitetura com salvaguardas antes do LLM; recusa para itens fora de escopo; escalonamento em sinais de alerta agudos; imposição de citação	Os tratamentos de risco estão implementados e testados; sem plano formal de tratamento com responsável, cronograma e critérios de aceitação

Cláusula 9: Avaliação de desempenho

Requisito	Implementação atual	Lacuna
9.1 Monitoramento, medição, análise e avaliação	O arcabouço de avaliação (7 dimensões, 315 casos); spans de OpenTelemetry; portões de custo/latência; imposição de paridade entre locais	O monitoramento é abrangente para a implementação de referência; sem relatório de desempenho no nível de revisão da direção
9.2 Auditoria interna	Sem auditoria interna formal	Sem programa de auditoria; sem critérios de auditoria; sem acompanhamento de achados de auditoria
9.3 Revisão pela direção	Sem revisão formal pela direção	Sem ciclo de revisão; sem entradas/saídas de revisão; sem itens de ação da revisão

Cláusula 10: Melhoria

Requisito	Implementação atual	Lacuna
10.1 Melhoria contínua	Achados de red-team incorporados ao banco de sementes; a regressão de avaliação impulsiona correções de código; o histórico de versões é publicado	A melhoria é reativa e interna ao repositório; sem programa formal de melhoria contínua
10.2 Não conformidade e ação corretiva	A regressão de avaliação falha a verificação de CI (um sinal, não um portão de fusão rígido - sem proteção de branch forçada); o processo de divulgação de segurança	Sem gestão formal de não conformidades; sem processo de análise de causa raiz; sem acompanhamento de ações corretivas

Mapeamento dos Critérios de Serviços de Confiança do SOC 2

O SOC 2 (System and Organization Controls 2) avalia organizações de serviços frente a cinco Critérios de Serviços de Confiança: Segurança, Disponibilidade, Integridade de Processamento, Confidencialidade e Privacidade.

Critérios comuns (Segurança) — Exigidos para todos os engajamentos

Controle	Implementação atual	Lacuna
CC6.1 Controles de acesso lógico	Sem autenticação em tempo de execução para a API de demonstração; acesso em nível de repositório; sem gestão de identidade de usuário	A produção precisaria de autenticação, autorização e processos de revisão de acesso
CC6.2 Controles de acesso físico	Herdado do provedor de nuvem (Google Cloud Run; sem infraestrutura física gerenciada pelo cliente)	A produção com componentes locais precisaria de controles de acesso físico
CC6.3 Criptografia de dados	HTTPS no Google Cloud Run (fornecido pela plataforma); sem criptografia em repouso (sem armazenamento persistente)	A produção precisaria de TLS 1.3 no mínimo; AES-256 em repouso para quaisquer dados armazenados
CC7.1 Gestão de mudanças	Os registros de decisões de arquitetura documentam as alterações; o arcabouço de avaliação valida as alterações; versionamento semântico; notas de versão	Sem processo formal de gestão de mudanças com fluxos de aprovação e procedimentos de rollback
CC7.2 Mitigação de riscos	Salvaguardas, arcabouço de avaliação, red-team, redação de PII, monitoramento com OpenTelemetry	Os controles existem; sem programa formal de mitigação de riscos com acompanhamento e relatórios
CC7.3 Resposta a incidentes	O processo de divulgação de segurança; varredura de segredos	Sem plano formal de resposta a incidentes; sem classificação de severidade; sem procedimentos de notificação
CC8.1 Gestão de mudanças (detalhada)	Fluxo de trabalho baseado em alterações; testes de regressão de avaliação; controle de versão	Sem conselho formal de aprovação de mudanças; sem checklist de validação pré-implantação

Disponibilidade

Controle	Implementação atual	Lacuna
A1.1 Disponibilidade do sistema	Única instância scale-to-zero do Google Cloud Run (scale-to-zero, cold start na primeira requisição após ociosidade; cerca de $0 em escala de demo); sem SLA	A produção precisaria de metas de disponibilidade, monitoramento, alertas e escalonamento de incidentes
A1.2 Backup e recuperação	Sem backup necessário (sem dados persistentes); corpus de avaliação e KB sob controle de versão	A produção com dados persistentes precisaria de procedimentos de backup, testes de recuperação, metas de RTO/RPO

Integridade de processamento

Controle	Implementação atual	Lacuna
PI1.1 Integridade de processamento	O arcabouço de avaliação valida a qualidade da saída (fidelidade, alucinação, citação); as salvaguardas impõem o escopo; portão de CI determinístico	O processamento é medido frente a limiares definidos; sem controles de integridade de processamento visíveis ao usuário final
PI1.2 Processamento de entrada	O classificador de escopo valida a entrada; a redação de PII higieniza a entrada; limites de comprimento de entrada	A validação de entrada existe para segurança; sem controles mais amplos de qualidade de entrada

Confidencialidade

Controle	Implementação atual	Lacuna
C1.1 Proteções de confidencialidade	Sem PHI/PII em armazenamento; texto do usuário excluído dos spans de OpenTelemetry; redação de PII na entrada/saída; a varredura de segredos impede a exposição de segredos	A confidencialidade é mantida por não armazenar dados sensíveis; a produção precisaria de controles ativos de confidencialidade para dados armazenados

Privacidade

Controle	Implementação atual	Lacuna
P1.1 Aviso de privacidade	Aviso de demonstração em cada resposta; o cartão do modelo; a postura regulatória	Sem aviso de privacidade formal; sem divulgação de coleta de dados; sem gestão de consentimento
P2.1 Gestão de consentimento	Consentimento de voz (modal de divulgação, alternância de adesão, avisos “Áudio NÃO retido”)	O consentimento existe apenas para voz; sem gestão de consentimento para processamento de dados em geral
P3.1 Coleta de dados	Nenhum dado pessoal coletado; 100% sintético	A produção precisaria de políticas de coleta de dados, limitação de finalidade e procedimentos de minimização
P4.1 Acesso e exclusão de dados	Nenhum dado pessoal a acessar ou excluir	A produção precisaria de procedimentos de solicitação de acesso e exclusão do titular dos dados
P6.1 Retenção de dados	Sem dados persistentes; sem retenção necessária	A produção precisaria de cronogramas de retenção, procedimentos de exclusão segura e monitoramento de retenção

Estado atual

A implementação de referência demonstra uma postura de governança alinhada tanto à ISO 42001 quanto aos princípios do SOC 2, implementada na profundidade que um projeto de referência de autor único pode razoavelmente alcançar:

Alinhamento à ISO 42001: Rastreabilidade baseada em registros de decisão (Cláusula 7.5), o arcabouço de avaliação como sistema de medição (Cláusula 9.1), as salvaguardas como tratamento de riscos (Cláusula 8.3), avaliação honesta de riscos (Cláusula 6.3), documentação transparente (Cláusulas 4, 7.4)
Alinhamento ao SOC 2: O arcabouço de avaliação como controle de integridade de processamento (PI1.1), as salvaguardas e a redação de PII como controles de confidencialidade (C1.1), privacidade desde a concepção (P1-P6), monitoramento com OpenTelemetry como controle de segurança (CC7.2), gestão de mudanças baseada em registros de decisão (CC7.1)

A avaliação honesta é de que esta é uma implementação de referência consciente de governança, não um sistema de gestão certificado. Nenhuma auditoria ISO 42001 foi conduzida. Nenhum engajamento SOC 2 foi realizado. O valor está em demonstrar que os padrões de governança são compreendidos e implementados em um nível que aceleraria uma certificação formal caso ela fosse buscada.

Caminho para produção

Obter a certificação ISO 42001 ou a atestação SOC 2 Tipo II:

SGSI formal (ISO 42001): Sistema de gestão de IA documentado com escopo definido, comprometimento da liderança, registro de riscos, objetivos, planos operacionais, avaliação de desempenho e programa de melhoria contínua; programa de auditoria interna; ciclo de revisão pela direção
Preparação para SOC 2 Tipo I: Controles documentados para todos os Critérios de Serviços de Confiança aplicáveis; coleta de evidências da existência dos controles; avaliação de prontidão por uma firma de contadores (CPA) qualificada
Atestação SOC 2 Tipo II: 6 a 12 meses de evidências de operação para todos os controles; auditoria independente por uma firma de CPA; relatório de atestação cobrindo o período de observação
Automação da coleta de evidências: Coleta e organização automatizadas das evidências de auditoria (logs de execução de avaliação, registros de alterações, logs de acesso, relatórios de incidentes, registros de treinamento); repositório de evidências com políticas de retenção
Monitoramento contínuo: Monitoramento em tempo real da eficácia dos controles; alertas automatizados sobre falhas de controle; testes periódicos de controles; painel para visibilidade do status dos controles
Gestão de fornecedores: Avaliações de riscos de terceiros para todos os provedores de serviço (provedores de LLM, plataformas de observabilidade, provedores de hospedagem); BAA quando aplicável; requisitos contratuais de segurança

Os padrões de governança do repositório — rastreabilidade por registros de decisão, portões do arcabouço de avaliação, arquitetura com salvaguardas em primeiro lugar, instrumentação com OpenTelemetry, documentação honesta — fornecem a fundação técnica. A lacuna está nas camadas organizacionais, processuais e de prontidão para auditoria.

Veja também

Mapeamento do NIST AI RMF — mapeamento do NIST AI RMF
Plano de registro de auditoria — plano de registro de auditoria
Prontidão para a HIPAA — prontidão para a HIPAA
Modelo de ameaças OWASP / ATLAS — modelo de ameaças
Decisão de observabilidade — projeto de observabilidade