Transforme riscos de LGPD em ações concretas.

O LGPD Enterprise Auditor faz do assistente de IA que você já usa um auditor orientado a evidências. Cada achado traz a prova, o artigo da lei e a correção, com score de 0 a 100 e plano de adequação com prazo e esforço.

Explorar no GitHub Ver como funciona
Ou instale agora, na raiz do projeto (macOS, Linux, WSL):
curl -fsSL https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/latest/download/install.sh | bash -s -- install
Windows, versão fixa e outras opções

Open source, licença MIT. Apoio técnico à conformidade: não é certificação nem parecer jurídico.

Trecho do relatório público de exemplo, gerado com /lgpd-saas sobre o AgendaFácil, um SaaS fictício e intencionalmente falho. Na demonstração você navega pelos 54 achados.

relatorio-auditoria-lgpd.html exemplo · dados fictícios
Relatório de auditoria LGPD AgendaFácil (SaaS fictício) · /lgpd-saas · escopo direcionado
Classificação crítica
54 não conformidades · cobertura de 82,9%
2 críticas24 altas22 médias6 baixas

Achados críticos

  • CríticoRota pública permite consultar e alterar dados de pacientesSE-03 · art. 46 · src/routes/agendamentos.js:31-38
  • CríticoOperadora usa dados dos pacientes para publicidade própriaOP-02 · art. 39 · public/index.html:7-15

O que fazer agora

  1. Tirar o Meta Pixel da página de agendamentoP · imediato
  2. Parar de gravar CPF e e-mail nos logsP · imediato
  3. Corrigir a rota pública de agendamentoP · imediato
itens de checklist, com ID fixo e peso definido
178
domínios de auditoria, de bases legais a IA/LLM
17
comandos: auditoria completa e 7 direcionadas
8
assistentes de IA compatíveis
6
Funciona com
  • Claude Code
  • Cursor
  • VS Code + GitHub Copilot
  • OpenCode
  • Codex
  • Gemini CLI

O code review vê o código. A LGPD pergunta pelo dado.

Um pull request aprovado pode gravar CPF em log, devolver campos demais numa API pública ou disparar um pixel antes do consentimento. Checklists manuais mudam de revisor para revisor, e a política de privacidade costuma dizer uma coisa enquanto o sistema faz outra.

Revisão sem critério fixo

  • Cada revisor olha uma coisa; o resultado não se compara entre releases.
  • “Está conforme” sem dizer onde está a prova.
  • Riscos sem prioridade: tudo parece urgente, ou nada parece.
  • Documentos e código avaliados por pessoas diferentes, em momentos diferentes.

Catálogo fixo, evidência por item

  • Todos os itens do catálogo dos módulos ativos são avaliados, sempre com o mesmo ID e o mesmo peso.
  • Nada é marcado como conforme sem evidência encontrada; no código, a evidência aponta arquivo e linha.
  • Severidade com prazo máximo e um plano de adequação priorizado.
  • Controles técnicos e documentais no mesmo checklist, com score técnico e documental separados.

  • Exposição desnecessária de dados

    APIs que devolvem mais campos do que a tela usa e formulários que pedem mais do que a finalidade exige.

    AP-02BL-04

  • Dados pessoais em logs

    CPF, e-mail, tokens ou payloads completos gravados em log sem mascaramento.

    SE-06

  • Autenticação e controle de acesso

    Tokens sem expiração ou algoritmo fixo, ausência de bloqueio de tentativas e de MFA quando o risco pede.

    AP-01SE-04AP-03

  • Isolamento entre contas e clientes

    Autorização que deixa um usuário ler ou alterar dados de outro usuário ou de outro cliente.

    SE-03

  • Consentimento e direitos do titular

    Rastreadores antes do aceite, consentimento sem prova e ausência de canal ou processo para atender os direitos do art. 18.

    CK-02CS-03DT-01DT-06

  • Política diferente do comportamento

    Política sem o conteúdo do art. 9º, rastreadores fora do inventário e hospedagem que altera o que o código configura.

    DT-04CK-07IN-01

Os códigos são IDs reais do catálogo. O auditor avalia cada item lendo o código e os documentos do projeto; o que exige acesso a painéis ou ao ambiente de produção fica como NAO_VERIFICADO, fora do score, nunca como conforme.

Do comando ao plano de adequação, no seu fluxo de trabalho.

O auditor é um conjunto de instruções em Markdown que fica dentro do seu projeto. Quem executa a análise é o assistente de IA; o framework define o que verificar, como provar e como pontuar.

  1. Instale no projeto

    Um comando na raiz do repositório pergunta qual assistente você usa e instala o framework, os comandos e, se quiser, a skill. Tudo local, por projeto: não existe instalação global.

  2. Escolha o cenário

    Rode /lgpd-full-audit para cobrir os 17 domínios, ou um cenário direcionado como /lgpd-saas, /lgpd-mobile ou /lgpd-ai-llm. Com a skill, basta pedir a auditoria em linguagem natural.

  3. O assistente lê antes de perguntar

    Consulta README, docs/, manifestos e infraestrutura, apresenta o contexto inferido e pergunta só o que faltar: natureza e porte do agente de tratamento, papel em cada fluxo (controlador ou operador) e o formato do relatório.

  4. Checklist com evidência

    O orquestrador ativa os módulos do cenário, mais os que os gatilhos pedirem (IA, menores de idade, app mobile, conteúdo de terceiros). Todos os itens do catálogo desses módulos são avaliados, e cada item aplicável recebe evidência e nível de confiança.

  5. Severidade, score e classificação

    Os achados recebem severidade e prazo; o score sai de uma fórmula fixa. Com achado crítico aberto, a classificação não passa de PARCIALMENTE_CONFORME.

  6. Relatório e plano de adequação

    O relatório sai em .md, .html ou nos dois, com as 8 seções obrigatórias e o plano em curto, médio e longo prazo. Repita a auditoria a cada release para acompanhar a evolução.

    O relatório descreve falhas que podem estar abertas: guarde-o fora de repositórios públicos.

Terminal · sessão ilustrativa
# na raiz do projeto$ curl -fsSL …/install.sh | bash -s -- install # no assistente> /lgpd-saas   Lido: README.md, package.json, vercel.json,        db/schema.sql, .github/workflows/ci.yml  ? Papel em cada fluxo: controlador ou operador?  ? Formato: .md | .md e .html | só .html   Cenário  saas_web (escopo direcionado)  Módulos  core legal governance appsec cloud devsecops  Itens    109 avaliados   Score 20/100 · CRITICO  Cobertura 82,9% (63 de 76 verificáveis)  Achados 2 crítico · 24 alto · 22 médio · 6 baixo  → relatorio-auditoria-lgpd.md  → relatorio-auditoria-lgpd.html

Representação ilustrativa: a forma das mensagens varia com o assistente. Os números são os do relatório de exemplo deste repositório.

Critérios fixos. Resultados que se explicam.

Cada número do relatório pode ser refeito à mão: o item, o peso, a evidência e a fórmula estão escritos. É isso que permite comparar uma auditoria com a seguinte.

Saiba exatamente onde corrigir

Cada item aplicável traz evidência classificada em dois eixos independentes, mais o nível de confiança. Um item só é CONFORME com evidência ENCONTRADA; no código, ela aponta arquivo e linha.

Grau de comprovação
ENCONTRADAPARCIALAUSENTE
Origem
TECNICADOCUMENTAL
AltoSE-06Logs com dados pessoais
AUSENTE (TECNICA), confiança ALTA: src/routes/agendamentos.js:29 grava nome, CPF e e-mail do paciente no console, que vira log da Vercel; src/auth.js:20 grava o e-mail em logins que falham.
Evidência do relatório de exemplo.

Priorize pelo risco, não pelo volume

Cada achado recebe severidade com prazo máximo. Para agente de pequeno porte, sem tratamento de alto risco nem exposição explorável confirmada, a severidade pode cair um nível; nunca em achado crítico com dado sensível ou de crianças, vazamento confirmado ou credencial exposta.

  • CríticoImediato
  • Alto30 dias
  • Médio90 dias
  • Baixo180 dias

Compare uma auditoria com a próxima

O score de 0 a 100 é determinístico: cada item vale pelo status e pesa pela criticidade, e as áreas têm pesos fixos. Cobertura abaixo de 80% marca o resultado como “score parcial”, e aceitar um risco nunca muda o número.

valor: CONFORME 1 · PARCIAL 0,5 · NAO_CONFORME 0
peso: CRITICO 4 · ALTO 3 · MEDIO 2 · BAIXO 1
score_area = 100 × Σ(valor × peso) / Σ(peso)
  1. 0–49CRITICO
  2. 50–69BAIXO_NIVEL
  3. 70–84PARCIALMENTE_CONFORME
  4. 85–94ALTA_CONFORMIDADE
  5. 95–100EXCELENTE

Entregue um plano que o time executa

O plano de adequação organiza as ações por horizonte. Cada ação traz os itens que resolve, o responsável sugerido e o esforço: P, M ou G. O resumo abre com “o que fazer agora”, de 3 a 5 ações.

  • Curto prazo0 a 30 dias
  • Médio prazo30 a 90 dias
  • Longo prazo90 a 180 dias
No exemplo: 29 ações, 15 delas de curto prazo.

Relatório em .md e .html

Você escolhe o formato no início. O .md é bom para versionar e comparar; o .html é um arquivo único e offline, com filtros, busca, tema claro e escuro e versão para impressão.

Fundamento legal em cada achado

Todo achado cita o artigo da LGPD aplicável. Só normas em vigor geram achados; projetos de lei ficam em monitoramento.

Relatório conferível

scripts/validate-report.py confere IDs, valores permitidos, a ligação entre itens e achados e o cálculo do score.

Modular e reutilizável

178 itens com IDs estáveis em 10 módulos. A mesma auditoria também existe como skill autocontida, com cobertura equivalente.

corelegalgovernanceappseccloudmobiledevsecopsai-llmeca-digitalplataformas-digitais

Uma auditoria completa e sete direcionadas.

core e legal entram sempre. Fora do /lgpd-full-audit, o relatório sai marcado como escopo direcionado e lista os domínios que não foram auditados.

/lgpd-full-auditfull_audit

Cobre os 17 domínios. Levanta a stack completa, os dados pessoais e sensíveis tratados, as integrações de terceiros, o contexto de DevSecOps e de IA/LLM, a presença de menores de 18 anos e a intermediação de conteúdo de terceiros.

Módulos ativados
  • core
  • legal
  • eca-digital
  • plataformas-digitais
  • governance
  • cloud
  • appsec
  • mobile
  • devsecops
  • ai-llm

/lgpd-saassaas_web

Stack web e backend, banco de dados, provedor de cloud, integrações (analytics, pagamentos, CRM) e dados pessoais ou sensíveis tratados. Audita a aplicação, a infraestrutura e o pipeline de entrega.

Módulos ativados
  • core
  • legal
  • governance
  • appsec
  • cloud
  • devsecops

/lgpd-webweb_site

Sites institucionais, landing pages, blogs e portais: base legal da captura de leads, minimização nos formulários, consentimento de cookies e trackers disparados antes do aceite, compartilhamento com marketing e CRM, política de privacidade e banner.

Módulos ativados
  • core
  • legal
  • governance
  • appsec
  • cloud

/lgpd-mobilemobile_app

iOS, Android, Flutter e React Native: permissões do app, armazenamento local, SDKs de tracking e analytics, uso de Firebase e de serviços cloud.

Módulos ativados
  • core
  • legal
  • governance
  • mobile
  • appsec
  • cloud

/lgpd-ai-llmai_llm_system

Provedores de IA/LLM, dados pessoais enviados em prompts, embeddings, RAG e fine-tuning, retenção e transferência internacional, base legal do tratamento em IA, prompt injection e vazamento contextual.

Módulos ativados
  • core
  • legal
  • governance
  • ai-llm
  • appsec

/lgpd-devsecopsdevsecops_pipeline

Plataforma de CI/CD, containers e Kubernetes, gestão de segredos, scans de segurança, supply chain, hardening e fluxo de deploy.

Módulos ativados
  • core
  • legal
  • devsecops
  • cloud
  • appsec

/lgpd-eca-digitaleca_digital_platform

LGPD art. 14 e ECA Digital (Lei nº 15.211/2025): aferição de idade, vinculação a um responsável e supervisão parental, privacidade padrão de perfis de menores, publicidade e perfilamento, loot boxes, denúncia e moderação, representante legal e relatório de transparência.

Módulos ativados
  • core
  • legal
  • eca-digital
  • governance
  • appsec
  • mobile

/lgpd-plataformas-digitaisdigital_platform

Decretos nº 12.975/2026 e nº 12.976/2026: canal de denúncia, notificação, remoção e contestação com prazos, moderação e riscos sistêmicos, anúncios e impulsionamento, guarda de registros de acesso, termos de uso, relatório de transparência e IA que gera ou altera imagem ou voz de pessoas.

Módulos ativados
  • core
  • legal
  • plataformas-digitais
  • governance
  • appsec
  • cloud

Em qualquer cenário, gatilhos acrescentam módulos: ai-llm com qualquer chamada a LLM ou IA generativa, eca-digital com usuários menores de 18 anos ou serviço que a lei presume acessado por eles (rede social, jogo, IA generativa), mobile com app iOS ou Android, entre outros.

Navegue por um relatório de verdade, sobre uma empresa que não existe.

Os dados abaixo foram extraídos do relatório público de exemplo: todos os 54 achados, o plano de adequação e o cálculo do score. Filtre por severidade ou prazo, busque por artigo ou arquivo e abra cada achado para ver a evidência.

Exemplo ilustrativo com dados fictícios. O AgendaFácil é um SaaS inventado e intencionalmente falho, criado para demonstrar o framework. Empresa, pessoas, CNPJ e dados não existem; não é o resultado da auditoria de nenhuma organização real.

relatorio-auditoria-lgpd · AgendaFácil (fictício) /lgpd-saassaas_web2026-10-03 Relatório completo (.md) Projeto de exemplo
CRITICO

Escopo direcionado · cobertura 82,9% (63 de 76 itens verificáveis)

Não conformidades por severidade

109 itens avaliados: 63 aplicáveis (9 conformes, 4 parciais, 50 não conformes), 33 não aplicáveis e 13 não verificados.

Score por área

  • bases_legais22,0
  • seguranca37,5
  • direitos_titular2,9
  • governanca5,5
  • infraestrutura0,0 · cobertura baixa
  • apis_integracoes37,5
  • ai_llm · eca_digital · plataformas_digitaisnão aplicável

Não conformidades

Mostrando 54 de 54 não conformidades

  • CríticoNC-01 · OP-02Operadora usa dados dos pacientes para publicidade própriaPrazo: ImediatoEsforço: P
    Problema
    A AgendaFácil trata os dados dos pacientes em nome das clínicas. Mesmo assim, instalou na página de agendamento um pixel de publicidade para as próprias campanhas. O pixel registra a visita à página de uma clínica específica e o evento de agendamento, e associa tudo a um identificador do navegador. Não há instrução nem autorização das clínicas para isso.
    Fundamento LGPD
    Art. 39 (tratamento segundo as instruções do controlador); art. 5º, VI e VII; art. 11, I e §1º; art. 42, §1º, I.
    Evidência
    AUSENTE (TECNICA + DOCUMENTAL), confiança MEDIA: o uso próprio está no código: public/index.html:7-15 (“campanhas de aquisição”), public/js/agendar.js:23 e README.md:24. Nenhuma instrução das clínicas documentada. Verificação que elevaria a confiança: captura de rede em produção e configuração do pixel no Gerenciador de Eventos da Meta.
    Correção recomendada
    Remover o pixel da página de agendamento. Publicidade própria só no site institucional, depois do aceite. Se algum uso próprio de dados dos pacientes for mantido, ele precisa de autorização das clínicas no contrato (OP-01), base legal do art. 11 e RIPD (GV-03).
    Responsável e prazo
    desenvolvedor líder (CTO), com decisão da sócia-fundadora (CEO) · prazo IMEDIATO
  • CríticoNC-02 · SE-03Rota pública permite consultar e alterar dados de pacientesPrazo: ImediatoEsforço: P
    Problema
    A página de agendamento é pública. Quando alguém agenda com um CPF que já existe naquela clínica, o sistema troca o telefone e o e-mail do paciente pelos informados e devolve um código; com o código, a rota de confirmação entrega o cadastro que já existia. Basta saber o CPF de um paciente para descobrir o nome e a data de nascimento dele, confirmar que é paciente da clínica e passar a receber os contatos no lugar dele.
    Fundamento LGPD
    Art. 46; art. 6º, V (qualidade dos dados) e VII (segurança); art. 11, §1º (revela que a pessoa é paciente).
    Evidência
    PARCIAL (TECNICA), confiança ALTA: src/routes/agendamentos.js:31-38 (atualização em caso de conflito) e :51-61 (consulta pelo código); nas rotas autenticadas o controle funciona (api/index.js:40-41, src/routes/clinica.js:13, :28).
    Correção recomendada
    Na rota pública, não atualizar cadastro existente: criar o agendamento sem alterar o paciente e deixar a correção de contatos para a clínica, autenticada (PATCH /api/clinica/pacientes/:id). A confirmação deve devolver só data e horário (AP-02).
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-03 · CK-02Meta Pixel disparado antes do consentimentoPrazo: ImediatoEsforço: P
    Problema
    O pixel é carregado e envia PageView no <head> da página, antes de o banner aparecer. Quem clica em “Rejeitar” já foi rastreado.
    Fundamento LGPD
    Art. 7º, I; art. 8º; art. 6º, III (necessidade).
    Evidência
    AUSENTE (TECNICA), confiança ALTA: public/index.html:8-15; consent.js só roda no fim da página (public/index.html:53).
    Correção recomendada
    Carregar qualquer rastreador de forma dinâmica, só depois de “Aceitar” (ver recomendacoes_tecnicas).
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-04 · TI-02Dados enviados ao exterior sem mecanismo legal demonstradoPrazo: 30 diasEsforço: M
    Problema
    A página de agendamento envia à Meta, nos EUA, identificadores do navegador (cookie _fbp, IP, user agent), a URL da clínica e o evento de agendamento. Os logs das funções, que hoje contêm CPF e e-mail (SE-06), ficam com a Vercel Inc., também nos EUA. Os termos desses provedores não foram localizados nem examinados.
    Fundamento LGPD
    Arts. 33 a 36; Res. CD/ANPD nº 19/2024 (prazo das CPC encerrado em 23/08/2025).
    Evidência
    AUSENTE (TECNICA + DOCUMENTAL), confiança BAIXA: o fluxo está comprovado em public/index.html:13-15 e public/js/agendar.js:23. O mecanismo não está: nenhum contrato, termo ou CPC em docs/lgpd/. Verificação que eleva a confiança: examinar os termos da Meta, da Vercel e do provedor do banco.
    Correção recomendada
    1. Remover o pixel da página de agendamento, o que elimina o fluxo para a Meta (OP-02). 2. Mapear as transferências que restarem (Vercel, provedor do banco, ferramentas futuras). 3. Examinar os termos padrão aceitos; se incorporarem as CPC, arquivá-los como evidência; se não incorporarem, assiná-las.
    Responsável e prazo
    CEO, com assessoria jurídica externa · prazo 30_DIAS
  • AltoNC-05 · SE-06CPF e e-mail gravados nos logsPrazo: ImediatoEsforço: P
    Problema
    Cada agendamento grava nome, CPF e e-mail do paciente no console, e cada login com falha grava o e-mail. Na Vercel, o console vira log da plataforma. Exemplo do que aparece hoje: [agendamento] novo paciente nome=Paciente Exemplo cpf=123.456.789-09 email=paciente@exemplo.example clinica=fisio-exemplo.
    Fundamento LGPD
    Art. 46; art. 6º, III e VII.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: src/routes/agendamentos.js:29; src/auth.js:20.
    Correção recomendada
    Registrar só IDs internos (paciente_id, clinica); para login, registrar o ID do usuário ou um hash do e-mail; expurgar os logs existentes no painel.
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-06 · AP-02API de confirmação devolve o cadastro completo do pacientePrazo: ImediatoEsforço: P
    Problema
    A rota pública de confirmação devolve todas as colunas do agendamento e do paciente, incluindo CPF, telefone, e-mail, data de nascimento e motivo da consulta. A tela usa apenas data, horário e nome. Qualquer pessoa com o código (link repassado, histórico do navegador, ferramenta de suporte) obtém tudo.
    Fundamento LGPD
    Art. 6º, III (necessidade); art. 46.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: src/routes/agendamentos.js:51-61; uso parcial em public/js/agendar.js:25-30.
    Correção recomendada
    Selecionar só a.data_hora e o primeiro nome; nunca devolver observacoes, CPF ou contato em rota pública.
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-07 · AP-01Token de login sem expiraçãoPrazo: ImediatoEsforço: P
    Problema
    Os tokens JWT são emitidos sem validade, algoritmo fixo nem audiência. Um token vazado dá acesso permanente à agenda da clínica, inclusive aos motivos de consulta.
    Fundamento LGPD
    Art. 46; art. 6º, VII.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: src/auth.js:24-27 (emissão); src/auth.js:36 (verificação sem algorithms).
    Correção recomendada
    expiresIn: '8h', algorithm: 'HS256' e audience na emissão; algorithms e audience na verificação; em seguida, avaliar token de renovação com revogação.
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-08 · IN-01vercel.json anula a CSP definida no códigoPrazo: ImediatoEsforço: P
    Problema
    O Express define uma CSP restritiva, mas as páginas estáticas, entre elas a que coleta CPF e dados de saúde, são servidas pela CDN da Vercel sem passar pelo Express. O único CSP que recebem é o do vercel.json, que permite scripts de qualquer origem, unsafe-inline e unsafe-eval, e não restringe o enquadramento da página. Para as respostas da API, qual cabeçalho prevalece depende da plataforma.
    Fundamento LGPD
    Art. 46; art. 6º, VII e VIII.
    Evidência
    PARCIAL (TECNICA), confiança MEDIA: vercel.json:12-15 contra api/index.js:22-34. Respostas de produção não coletadas; curl -I na página e na API elevaria a confiança.
    Correção recomendada
    Substituir o valor no vercel.json pela mesma política do código (default-src 'self'; script-src 'self'; connect-src 'self'; frame-ancestors 'none'), acrescentar Strict-Transport-Security e conferir com curl -I. A política restritiva só funciona depois de retirar o pixel inline (OP-02).
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-09 · OP-01Sem contrato com as clínicas controladorasPrazo: 30 diasEsforço: M
    Problema
    Não há termos de uso nem contrato que estabeleça que a clínica é controladora dos dados dos pacientes e que a AgendaFácil trata esses dados por instrução dela. O rascunho da política apresenta a AgendaFácil como responsável por tudo.
    Fundamento LGPD
    Art. 5º, VI e VII; art. 39; art. 42, §1º, I.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: README.md:16; nenhum termo em public/ nem em docs/lgpd/; declaração da fundadora; docs/lgpd/politica-de-privacidade.md:9.
    Correção recomendada
    Termos de uso com cláusulas de operador: objeto, instruções, confidencialidade, segurança, lista de suboperadores, aviso de incidentes, apoio a pedidos de titulares e ao RIPD da clínica, devolução e eliminação ao fim do contrato. Pode partir de .agents/lgpd-enterprise-auditor/templates/dpa-template.md.
    Responsável e prazo
    CEO e assessoria jurídica · prazo 30_DIAS
  • AltoNC-10 · OP-03Suboperadores não informados às clínicasPrazo: 30 diasEsforço: P
    Problema
    A Vercel processa as requisições com o motivo da consulta, e o provedor do banco armazena esses dados. As clínicas não são informadas de que esses suboperadores existem.
    Fundamento LGPD
    Art. 39.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: README.md:22-23 identifica os provedores; não há contrato nem lista de suboperadores entregue às clínicas (OP-01).
    Correção recomendada
    Listar os suboperadores nos termos com as clínicas (OP-01) e avisá-las antes de trocar de provedor.
    Responsável e prazo
    CEO · prazo 30_DIAS
  • AltoNC-11 · OP-04Sem processo de aviso de incidentes às clínicasPrazo: 30 diasEsforço: M
    Problema
    Não há procedimento, responsáveis nem modelo de aviso para incidentes de segurança. Nos dados dos pacientes, a AgendaFácil precisa avisar as clínicas sem demora, para que elas comuniquem a ANPD e os titulares. A comunicação dos dados próprios é contada em GV-08.
    Fundamento LGPD
    Art. 39; art. 48; Res. CD/ANPD nº 15/2024 (comunicação em 3 dias úteis, complementável em 20 dias úteis).
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nenhum plano ou runbook no repositório; declaração da fundadora.
    Correção recomendada
    Adotar .agents/lgpd-enterprise-auditor/templates/incident-response-template.md, definir quem decide e quem avisa, e fixar no contrato o prazo de aviso às clínicas (por exemplo, 24 horas).
    Responsável e prazo
    CEO e CTO · prazo 30_DIAS
  • AltoNC-12 · SE-07Sem trilha de auditoria de acessos a dados de pacientesPrazo: 30 diasEsforço: M
    Problema
    Não há registro de qual usuário consultou a agenda ou alterou dados de qual paciente.
    Fundamento LGPD
    Art. 46; art. 6º, X; art. 37.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: api/index.js:38-41; src/routes/clinica.js:8-33.
    Correção recomendada
    Middleware que registre usuário, clínica, rota, ID do paciente e horário, sem dados pessoais, em armazenamento com retenção definida.
    Responsável e prazo
    CTO · prazo 30_DIAS
  • AltoNC-13 · DS-02Sem varredura de dependências e sem nenhuma outra varredura no CIPrazo: 30 diasEsforço: P
    Problema
    O pipeline não verifica vulnerabilidades em dependências, e não há nenhuma outra varredura de segurança.
    Fundamento LGPD
    Art. 46; art. 49.
    Evidência
    AUSENTE (TECNICA), confiança MEDIA: .github/workflows/ci.yml:16-18; nenhum dependabot.yml no repositório. As configurações de segurança do GitHub não foram vistas.
    Correção recomendada
    npm audit --audit-level=high no job build e Dependabot semanal.
    Responsável e prazo
    CTO · prazo 30_DIAS
  • AltoNC-14 · DT-01Sem canal para exercício de direitos nos tratamentos própriosPrazo: 30 diasEsforço: P
    Problema
    Nos tratamentos em que é controladora (contas dos usuários das clínicas e rastreamento), a AgendaFácil não informa os direitos nem como exercê-los. O único contato é um e-mail comercial genérico.
    Fundamento LGPD
    Arts. 18 e 19; art. 9º, VII.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: docs/lgpd/politica-de-privacidade.md:36; public/index.html:48.
    Correção recomendada
    Endereço ou formulário específico de privacidade no aviso e no rodapé, com prazo de resposta (imediato em formato simplificado ou até 15 dias, art. 19).
    Responsável e prazo
    CEO · prazo 30_DIAS
  • AltoNC-15 · DT-03Aviso de privacidade não publicadoPrazo: 30 diasEsforço: P
    Problema
    O rodapé e o banner de cookies apontam para /privacidade, mas não existe página nesse endereço. O único texto é um rascunho dentro do repositório.
    Fundamento LGPD
    Art. 9º, caput (acesso facilitado e ostensivo).
    Evidência
    PARCIAL (TECNICA + DOCUMENTAL), confiança MEDIA: public/index.html:49; nenhuma página em public/, que é a pasta publicada (vercel.json:4); rascunho em docs/lgpd/politica-de-privacidade.md. Produção não consultada.
    Correção recomendada
    Publicar o aviso revisado (DT-04) em public/privacidade.html e testar o link em produção.
    Responsável e prazo
    CTO · prazo 30_DIAS
  • AltoNC-16 · GV-01Sem registro das operações de tratamentoPrazo: 30 diasEsforço: M
    Problema
    Não existe inventário com finalidade, papel, base legal, categorias de titulares, compartilhamentos, retenção e medidas de segurança. O operador também deve manter o registro das operações que realiza.
    Fundamento LGPD
    Art. 37.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: docs/lgpd/ contém só o rascunho da política; README.md:27-29 lista dados, sem os demais elementos; declaração da fundadora.
    Correção recomendada
    Registro versionado em docs/lgpd/, separando o que a AgendaFácil trata como operadora (pacientes) do que trata como controladora (contas, logs, rastreamento).
    Responsável e prazo
    CEO, com o encarregado · prazo 30_DIAS
  • AltoNC-17 · GV-02Encarregado não indicadoPrazo: 30 diasEsforço: P
    Problema
    Não há encarregado indicado nem contato divulgado.
    Fundamento LGPD
    Art. 41; Res. CD/ANPD nº 18/2024.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: docs/lgpd/politica-de-privacidade.md:36; public/index.html:47-51.
    Correção recomendada
    Indicar encarregado por ato escrito, datado e assinado (pode ser pessoa jurídica, como um serviço de DPO externo) e divulgar o contato no site.
    Responsável e prazo
    CEO · prazo 30_DIAS
  • AltoNC-18 · GV-03 risco aceitoSem RIPD para o uso próprio de dados da página de agendamentoPrazo: 30 diasEsforço: G
    Problema
    Como controladora do rastreamento para fins próprios, a AgendaFácil faz um tratamento de alto risco (revela busca por atendimento de saúde, em escala relevante) sem relatório de impacto. O RIPD dos dados de saúde inseridos no agendamento é das clínicas.
    Fundamento LGPD
    Art. 38; art. 5º, XVII.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nenhum RIPD em docs/lgpd/; declaração da fundadora.
    Correção recomendada
    Encerrar o tratamento, removendo o pixel da página de agendamento (OP-02). Encerrado o uso próprio, o item deixa de ser aplicável. Se algum uso próprio for mantido, elaborar o RIPD com .agents/lgpd-enterprise-auditor/templates/ripd-template.md. - accepted_by: Ana Exemplo, sócia-administradora e CEO (pessoa fictícia); - accepted_at: 2026-10-03; - justification: o pixel será removido da página de agendamento em até 7 dias (ação 1), o que encerra o tratamento. Elaborar um RIPD, com esforço de mais de uma semana, para um tratamento em extinção não se justifica para uma equipe de 3 pessoas. Se em 90 dias ainda houver qualquer uso próprio de dados da página de agendamento, o RIPD será elaborado; - deadline_suggestion: 30_DIAS (mantido); - accepted_deadline: 90_DIAS; - review_at: 2026-12-31. - O aceite não altera status, severidade nem score: o item segue NAO_CONFORME, ALTO, com valor 0 e peso 3.
    Responsável e prazo
    CEO, com o encarregado · prazo 30_DIAS (adiado pelo aceite de risco para 90_DIAS; o aceite não altera status, severidade nem score)
  • AltoNC-19 · GV-06Sem canal de denúncia de provedor de aplicaçõesPrazo: 30 diasEsforço: P
    Problema
    Não há canal permanente de denúncia, exigido de todo provedor de aplicações de internet desde 20/07/2026. O rodapé traz só um e-mail de contato geral.
    Fundamento LGPD
    Decreto nº 8.771/2016, art. 16-A, II (redação do Decreto nº 12.975/2026). Correlato LGPD: art. 6º, VI (transparência).
    Evidência
    AUSENTE (TECNICA), confiança ALTA: public/index.html:48.
    Correção recomendada
    Página “Fale conosco sobre privacidade e denúncias” com formulário ou e-mail monitorado, que preveja expressamente a notificação de conteúdo ilícito.
    Responsável e prazo
    CEO · prazo 30_DIAS
  • AltoNC-20 · BL-02Base legal dos tratamentos próprios não documentadaPrazo: 30 diasEsforço: P
    Problema
    A AgendaFácil é controladora dos dados das contas dos usuários das clínicas, mas nenhum documento diz qual base legal sustenta esse tratamento.
    Fundamento LGPD
    Art. 7º; art. 6º, X.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: nenhum documento nomeia a base: docs/lgpd/politica-de-privacidade.md:22-26; declaração da fundadora. A relação contratual só aparece de forma indireta (README.md:16; db/schema.sql:11-18).
    Correção recomendada
    Indicar a base de cada tratamento próprio no registro das operações (GV-01) e no aviso de privacidade (DT-04).
    Responsável e prazo
    CEO e assessoria jurídica · prazo 30_DIAS
  • AltoNC-21 · SE-04Login sem segundo fator nem política de senhaPrazo: 30 diasEsforço: M
    Problema
    O acesso ao painel, que mostra dados de saúde dos pacientes, depende só de e-mail e senha. Não há segundo fator nem regra mínima para a senha.
    Fundamento LGPD
    Art. 46.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: src/auth.js:11-29 (login só com e-mail e senha); src/auth.js:7-9 (gera o hash, sem validar a senha); não há rota de criação ou troca de senha.
    Correção recomendada
    Segundo fator (TOTP) para usuários de clínica e de administração e política de senha (tamanho mínimo e bloqueio de senhas vazadas).
    Responsável e prazo
    CTO · prazo 30_DIAS
  • AltoNC-22 · TI-04Transferência internacional não informada ao titularPrazo: 30 diasEsforço: P
    Problema
    O rascunho do aviso de privacidade não diz que dados de navegação vão para a Meta e que os logs ficam com a Vercel, ambas nos EUA.
    Fundamento LGPD
    Art. 9º, V; art. 33.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: docs/lgpd/politica-de-privacidade.md:22-36 não menciona transferência nem destinatários.
    Correção recomendada
    Informar no aviso os destinos, os provedores e o mecanismo adotado; nos dados dos pacientes, informar as clínicas.
    Responsável e prazo
    CEO e assessoria jurídica · prazo 30_DIAS
  • AltoNC-23 · TI-05Dado que revela busca por atendimento de saúde enviado ao exterior sem proteçãoPrazo: ImediatoEsforço: P
    Problema
    O pixel envia à Meta, nos EUA, a visita e o agendamento na página de uma clínica, o que revela que a pessoa procura atendimento de saúde (art. 11, §1º). Não há hipótese do art. 11 nem medida de proteção para esse envio.
    Fundamento LGPD
    Arts. 11, 33 e 46.
    Evidência
    AUSENTE (TECNICA), confiança MEDIA: public/index.html:13-15 e public/js/agendar.js:23 (mesma evidência de OP-02); .env.example:5-6 e vercel.json:3 mostram o banco e as funções em São Paulo.
    Correção recomendada
    Remover o pixel da página de agendamento (OP-02); com isso o item deixa de ter objeto.
    Responsável e prazo
    CTO · prazo IMEDIATO
  • AltoNC-24 · GV-08Sem processo de comunicação de incidentes nos dados própriosPrazo: 30 diasEsforço: M
    Problema
    Nos dados em que a AgendaFácil é controladora (contas das clínicas e rastreamento), cabe a ela comunicar a ANPD e os titulares em até 3 dias úteis. Não há procedimento, responsáveis nem modelo para isso.
    Fundamento LGPD
    Art. 48; Res. CD/ANPD nº 15/2024.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nenhum plano ou runbook no repositório; declaração da fundadora.
    Correção recomendada
    No mesmo documento de OP-04, definir quem avalia o risco, quem comunica a ANPD e os titulares e em que prazo.
    Responsável e prazo
    CEO e CTO · prazo 30_DIAS
  • AltoNC-25 · GV-09Operadores sem contrato de proteção de dados demonstradoPrazo: 30 diasEsforço: P
    Problema
    A Vercel processa as requisições com o motivo da consulta, e o provedor do banco armazena esses dados. Não foram localizados contratos de proteção de dados (DPA) com eles.
    Fundamento LGPD
    Art. 39; art. 46.
    Evidência
    AUSENTE (DOCUMENTAL), confiança BAIXA: nenhum DPA em docs/lgpd/; os termos padrão aceitos no cadastro não foram examinados. Verificação que eleva a confiança: reunir os DPAs e os termos da Vercel e do provedor do banco.
    Correção recomendada
    Baixar e arquivar os DPAs que os provedores oferecem e verificar a cobertura de CPC (TI-02).
    Responsável e prazo
    CEO · prazo 30_DIAS
  • AltoNC-26 · DS-08Sem varredura de segredos no repositórioPrazo: 30 diasEsforço: P
    Problema
    Nada verifica se uma senha, token ou chave foi parar no código ou no histórico do git.
    Fundamento LGPD
    Art. 46.
    Evidência
    AUSENTE (TECNICA), confiança MEDIA: .github/workflows/ci.yml:9-30 não tem etapa de varredura de segredos; .gitignore:2-4 exclui o .env. A proteção nativa do GitHub contra segredos não foi vista.
    Correção recomendada
    Ligar a proteção contra segredos do GitHub e rodar uma varredura do histórico (por exemplo, gitleaks) no CI.
    Responsável e prazo
    CTO · prazo 30_DIAS
  • MédioNC-27 · CK-03Revogação que não apaga o identificador da MetaPrazo: 90 diasEsforço: P
    Problema
    O usuário consegue rever a escolha, e a recusa chama fbq('consent', 'revoke'), o que interrompe os eventos seguintes. Mas o cookie _fbp e o script já carregado permanecem no navegador.
    Fundamento LGPD
    Art. 8º, §5º; art. 18, IX.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: public/js/consent.js:6-9 e :26-29; public/index.html:50.
    Correção recomendada
    Na revogação, apagar o cookie _fbp e não recarregar o pixel.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-28 · CK-04Escolha de cookies sem provaPrazo: 90 diasEsforço: M
    Problema
    A escolha fica apenas no navegador, sem versão do banner nem categorias.
    Fundamento LGPD
    Art. 8º, §2º.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: public/js/consent.js:12.
    Correção recomendada
    Registrar no servidor um identificador aleatório, data, versão do banner e categorias aceitas.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-29 · CK-05Consentimento de cookies sem categoriasPrazo: 90 diasEsforço: M
    Problema
    O banner oferece só “Aceitar” ou “Rejeitar” tudo, sem separar finalidades.
    Fundamento LGPD
    Art. 8º, §4º.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: public/index.html:41-45.
    Correção recomendada
    Categorias separadas (necessários, medição, publicidade), sem pré-marcação.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-30 · DT-02Sem fluxo para atender pedidos nos tratamentos própriosPrazo: 90 diasEsforço: P
    Problema
    Não há procedimento escrito, com prazo, responsável e confirmação, para atender pedidos sobre os dados de uma conta de usuário de clínica. A falta de recurso no sistema é contada em DT-06.
    Fundamento LGPD
    Art. 18, §§3º a 5º; art. 19.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nenhum procedimento em docs/lgpd/; declaração da fundadora.
    Correção recomendada
    Procedimento de uma página (quem recebe, como executa, prazo, registro), suficiente para o volume atual.
    Responsável e prazo
    CEO · prazo 90_DIAS
  • MédioNC-31 · DT-04Aviso de privacidade incompleto e com papéis trocadosPrazo: 30 diasEsforço: M
    Problema
    O rascunho identifica a empresa e menciona cookies de forma genérica. Faltam o tratamento das contas das clínicas, a Meta como destinatária, base legal, retenção, direitos e encarregado. Além disso, o texto fala aos pacientes como se a AgendaFácil fosse a controladora dos dados do agendamento.
    Fundamento LGPD
    Art. 9º; art. 6º, I (finalidade específica).
    Evidência
    PARCIAL (DOCUMENTAL), confiança ALTA: docs/lgpd/politica-de-privacidade.md:3-36.
    Correção recomendada
    Reescrever com .agents/lgpd-enterprise-auditor/templates/privacy-policy-template.md: tratar das contas e dos cookies e explicar que, nos agendamentos, a controladora é a clínica.
    Responsável e prazo
    CEO e assessoria jurídica · prazo 30_DIAS
  • MédioNC-32 · GV-04Sem política de retenção dos dados própriosPrazo: 90 diasEsforço: P
    Problema
    Não há prazo definido para manter contas de usuários das clínicas e logs, nem fundamento do art. 16 para o que é conservado. Os prazos dos dados dos pacientes são definidos pelas clínicas e entram no contrato (OP-01) e na rotina de expurgo (OP-06).
    Fundamento LGPD
    Arts. 15 e 16.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/lgpd/; declaração da fundadora.
    Correção recomendada
    Prazos por categoria. Exemplos: - contas: até o fim do contrato, mais o prazo legal; - logs de aplicação: 90 dias; - registros de acesso: 6 meses (MCI, art. 15; ver IN-04).
    Responsável e prazo
    CEO · prazo 90_DIAS
  • MédioNC-33 · OP-06Sem devolução ou eliminação dos dados ao fim do contratoPrazo: 90 diasEsforço: M
    Problema
    O sistema não tem rotina para devolver ou eliminar os dados de uma clínica que encerra o contrato, nem para expurgar registros nos prazos que a clínica definir.
    Fundamento LGPD
    Arts. 15 e 16; art. 39.
    Evidência
    AUSENTE (TECNICA + DOCUMENTAL), confiança MEDIA: db/schema.sql:20-39; nenhuma rotina no código nem agendamento no vercel.json ou no CI; nenhum procedimento escrito.
    Correção recomendada
    Exportação em lote por clínica e job agendado que elimine ou anonimize registros vencidos, gravando o que foi feito e alcançando os backups conforme a política do provedor.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-34 · AP-03APIs sem limitação de taxaPrazo: 90 diasEsforço: P
    Problema
    Login e agendamento público aceitam requisições ilimitadas, o que também deixa o login sem proteção contra força bruta.
    Fundamento LGPD
    Art. 46.
    Evidência
    AUSENTE (TECNICA), confiança MEDIA: api/index.js:36-41; package.json:15-22. As regras do firewall da plataforma não foram vistas.
    Correção recomendada
    express-rate-limit em /api/login e POST /api/agendamentos, ou o firewall da plataforma.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-35 · TI-01Envios de dados ao exterior não mapeadosPrazo: 30 diasEsforço: P
    Problema
    Nenhum documento lista para onde os dados saem do País, por qual provedor e para quê. Os destinos só aparecem no código e na fala da fundadora.
    Fundamento LGPD
    Arts. 33 e 37.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/lgpd/; public/index.html:13-15 (Meta) e README.md:22 (Vercel) são as únicas pistas; declaração da fundadora.
    Correção recomendada
    Incluir no registro das operações (GV-01) uma tabela de destinos, provedores, dados e mecanismo do art. 33.
    Responsável e prazo
    CEO, com o encarregado · prazo 30_DIAS
  • MédioNC-36 · DT-06Sistema sem recurso para corrigir, exportar ou excluir contasPrazo: 90 diasEsforço: M
    Problema
    Não há rota nem tela para consultar, corrigir, exportar ou excluir os dados de uma conta de usuário de clínica. Qualquer pedido depende de alteração manual no banco.
    Fundamento LGPD
    Art. 18, III a VI.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: src/routes/clinica.js:1-55 e api/index.js:38-41 não têm rota de conta.
    Correção recomendada
    Rotas autenticadas para ver, corrigir, exportar e excluir a própria conta; exclusão com confirmação.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-37 · DT-07Titular não tem como saber com quem os dados são compartilhadosPrazo: 30 diasEsforço: P
    Problema
    Nenhum documento ou tela informa que a Meta recebe dados de navegação nem que a Vercel e o provedor do banco tratam os dados das contas.
    Fundamento LGPD
    Art. 18, VII; art. 9º, V.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: docs/lgpd/politica-de-privacidade.md:36 (pendência registrada no próprio rascunho); public/index.html:42.
    Correção recomendada
    Listar destinatários e finalidades no aviso de privacidade e responder a esse pedido pelo canal de direitos (DT-01).
    Responsável e prazo
    CEO e assessoria jurídica · prazo 30_DIAS
  • MédioNC-38 · DT-10Pedidos de titulares sem registroPrazo: 90 diasEsforço: P
    Problema
    Não existe registro dos pedidos recebidos, das respostas e da confirmação de execução.
    Fundamento LGPD
    Art. 6º, X; art. 18.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/lgpd/; declaração da fundadora.
    Correção recomendada
    Planilha ou sistema de chamados com data, tipo de pedido, resposta e data de execução.
    Responsável e prazo
    CEO · prazo 90_DIAS
  • MédioNC-39 · GV-12Dados próprios nunca são eliminadosPrazo: 90 diasEsforço: M
    Problema
    Não há rotina que elimine contas inativas e logs ao fim de um prazo, nem rota de exclusão. A eliminação dos dados dos pacientes é contada em OP-06.
    Fundamento LGPD
    Arts. 15 e 16.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: nenhuma rotina de expurgo no código (package.json:7-11, src/); db/schema.sql:11-18 não tem campo de desativação nem de exclusão.
    Correção recomendada
    Depois de definir os prazos (GV-04), agendar o expurgo e incluir backups e provedores.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-40 · GV-14Retenções legais não identificadasPrazo: 90 diasEsforço: P
    Problema
    Nenhum documento identifica o que precisa ser guardado por lei e por quanto tempo, como os registros de acesso do MCI (6 meses) e os documentos fiscais.
    Fundamento LGPD
    Art. 16, I; MCI, art. 15.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/lgpd/; declaração da fundadora.
    Correção recomendada
    Listar as retenções legais na política de retenção (GV-04), com o prazo e a norma de cada uma.
    Responsável e prazo
    CEO · prazo 90_DIAS
  • MédioNC-41 · GV-15Sem histórico das decisões de privacidadePrazo: 90 diasEsforço: P
    Problema
    A pasta docs/lgpd/ tem só um rascunho de política. Não há versões anteriores, atas nem registro de quem decidiu o quê.
    Fundamento LGPD
    Art. 6º, X; art. 50.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: docs/lgpd/ contém um único arquivo; declaração da fundadora.
    Correção recomendada
    Manter os documentos de privacidade versionados no repositório e registrar as decisões (por exemplo, a remoção do pixel).
    Responsável e prazo
    CEO, com o encarregado · prazo 90_DIAS
  • MédioNC-42 · GV-16Sem política de segurança da informaçãoPrazo: 90 diasEsforço: M
    Problema
    Não há documento que defina regras de acesso, senhas, uso de dados de produção e resposta a falhas.
    Fundamento LGPD
    Arts. 46 e 50.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/; declaração da fundadora.
    Correção recomendada
    Política curta, de uma ou duas páginas, proporcional a uma equipe de três pessoas.
    Responsável e prazo
    CEO e CTO · prazo 90_DIAS
  • MédioNC-43 · CK-06Banner de cookies sem informação claraPrazo: 90 diasEsforço: P
    Problema
    O banner aparece e funciona, mas diz apenas que os cookies servem para “melhorar sua experiência”. Não informa a finalidade real (publicidade) nem o terceiro que recebe os dados (Meta).
    Fundamento LGPD
    Art. 8º; art. 9º, I e V.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: public/index.html:41-45.
    Correção recomendada
    Texto que nomeie as finalidades e os terceiros, com link para a política de cookies.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-44 · CK-07Pixel e identificadores sem inventário nem política de cookiesPrazo: 30 diasEsforço: P
    Problema
    Não há política de cookies nem lista dos rastreadores usados. O rascunho da política diz só que o site usa cookies.
    Fundamento LGPD
    Art. 9º; art. 37.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: docs/lgpd/politica-de-privacidade.md:28-30; nenhum outro documento em docs/lgpd/.
    Correção recomendada
    Política de cookies com .agents/lgpd-enterprise-auditor/templates/cookie-policy-template.md, listando cada cookie ou SDK, finalidade e prazo.
    Responsável e prazo
    CEO e CTO · prazo 30_DIAS
  • MédioNC-45 · AP-05APIs públicas sem inventárioPrazo: 90 diasEsforço: P
    Problema
    As rotas abertas à internet (/api/agendamentos e /api/login) não estão listadas em documento algum, com os dados que cada uma expõe.
    Fundamento LGPD
    Arts. 37 e 46.
    Evidência
    AUSENTE (DOCUMENTAL), confiança ALTA: api/index.js:38-41 é a única fonte; nada em README.md nem em docs/.
    Correção recomendada
    Tabela com rota, autenticação, dados recebidos e devolvidos e responsável, revisada a cada mudança.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-46 · DS-07Sem análise estática nem dinâmica de segurançaPrazo: 90 diasEsforço: P
    Problema
    O pipeline roda lint e testes, mas nenhuma análise de segurança do código (SAST) nem da aplicação em execução (DAST).
    Fundamento LGPD
    Art. 46; art. 49.
    Evidência
    AUSENTE (TECNICA), confiança MEDIA: .github/workflows/ci.yml:16-18; nenhum fluxo de CodeQL no repositório. As configurações de segurança do GitHub não foram vistas.
    Correção recomendada
    CodeQL (ou equivalente) no CI; DAST básico antes de mudanças grandes.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-47 · DS-09Pipeline com permissões padrão e actions sem versão fixaPrazo: 90 diasEsforço: P
    Problema
    O workflow não declara permissions, então o token roda com as permissões padrão do repositório. As actions usam a tag v4, que pode ser movida, e o deploy baixa a CLI da Vercel sem versão.
    Fundamento LGPD
    Art. 46.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: .github/workflows/ci.yml:12-13 e :25-26; nenhum bloco permissions.
    Correção recomendada
    Declarar permissions: contents: read, fixar as actions pelo hash do commit e a CLI por versão.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • MédioNC-48 · IN-16Runtime fora de suporte fixado no projetoPrazo: 90 diasEsforço: P
    Problema
    O projeto está preso ao Node.js 20, linha que deixou de receber correções de segurança em abril de 2026, e não tem rotina para atualizar o runtime.
    Fundamento LGPD
    Art. 46.
    Evidência
    AUSENTE (TECNICA), confiança MEDIA: .github/workflows/ci.yml:15; package.json:12-14; README.md:20. A versão efetiva em produção depende do painel da Vercel, não conferido.
    Correção recomendada
    Migrar para uma linha do Node.js com suporte, fixá-la no CI e no package.json e rever a versão a cada ciclo de suporte.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • BaixoNC-49 · OP-05Apoio incompleto às clínicas nos pedidos dos pacientesPrazo: 90 diasEsforço: M
    Problema
    A clínica consegue corrigir dados cadastrais, mas não há como gerar cópia, exportar ou eliminar o cadastro de um paciente.
    Fundamento LGPD
    Art. 39; art. 18, II, V e VI.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: src/routes/clinica.js:21-33.
    Correção recomendada
    Rotas autenticadas para a clínica exportar (JSON ou CSV) e eliminar ou anonimizar um paciente, com registro da execução.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • BaixoNC-50 · DS-03Sem SBOMPrazo: 180 diasEsforço: P
    Problema
    Não há inventário das dependências gerado a cada build.
    Fundamento LGPD
    Art. 46; art. 6º, X.
    Evidência
    AUSENTE (TECNICA), confiança ALTA: .github/workflows/ci.yml:9-30.
    Correção recomendada
    Gerar SBOM CycloneDX no CI e guardá-lo como artefato.
    Responsável e prazo
    CTO · prazo 180_DIAS
  • BaixoNC-51 · SE-10Validação de entrada incompleta no agendamentoPrazo: 90 diasEsforço: P
    Problema
    O agendamento confere se os campos obrigatórios vieram e limita o tamanho do corpo, mas não valida o formato de CPF, e-mail, telefone e datas.
    Fundamento LGPD
    Art. 46; art. 6º, V.
    Evidência
    PARCIAL (TECNICA), confiança ALTA: src/routes/agendamentos.js:20-22; api/index.js:36; a saída usa textContent (public/js/agendar.js:28).
    Correção recomendada
    Validar formato e tamanho de cada campo no servidor.
    Responsável e prazo
    CTO · prazo 90_DIAS
  • BaixoNC-52 · GV-17Equipe sem treinamento de privacidadePrazo: 180 diasEsforço: P
    Problema
    Não há registro de orientação ou treinamento dos três sócios sobre proteção de dados.
    Fundamento LGPD
    Art. 41, §2º, III; art. 50.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/; declaração da fundadora.
    Correção recomendada
    Uma sessão anual, registrada, sobre o papel de operadora, logs e incidentes.
    Responsável e prazo
    encarregado · prazo 180_DIAS
  • BaixoNC-53 · IN-15Divisão de responsabilidades com os provedores não documentadaPrazo: 180 diasEsforço: P
    Problema
    Nenhum documento diz o que cabe à Vercel e ao provedor do banco e o que cabe à AgendaFácil (certificados, backups, atualizações, cabeçalhos).
    Fundamento LGPD
    Arts. 46 e 50.
    Evidência
    AUSENTE (DOCUMENTAL), confiança MEDIA: nada em docs/ nem no README.md:18-25; declaração da fundadora.
    Correção recomendada
    Quadro de uma página com as responsabilidades de cada parte.
    Responsável e prazo
    CTO · prazo 180_DIAS
  • BaixoNC-54 · DT-05Política sem indicação de versãoPrazo: 180 diasEsforço: P
    Problema
    O rascunho da política traz a data de atualização, mas não um número de versão nem o histórico das mudanças.
    Fundamento LGPD
    Art. 6º, VI; art. 9º.
    Evidência
    PARCIAL (DOCUMENTAL), confiança MEDIA: docs/lgpd/politica-de-privacidade.md:3.
    Correção recomendada
    Numerar as versões e manter o histórico ao publicar o aviso.
    Responsável e prazo
    CEO e assessoria jurídica · prazo 180_DIAS

Plano de adequação

Esforço P até 1 dia, M até 1 semana, G mais de 1 semana. IMEDIATO significa até 7 dias.

Curto prazo (0-30 dias) 15 ações

  1. 1

    Remover o Meta Pixel da página de agendamento; se mantido no site institucional, carregar só após o aceite e apagar _fbp na revogação

    • OP-02
    • CK-02
    • CK-03
    • TI-02
    • TI-05
    Responsável
    CTO
    Esforço
    P
    Prazo
    IMEDIATO
  2. 2

    Retirar CPF, nome e e-mail dos logs e expurgar os logs existentes

    • SE-06
    Responsável
    CTO
    Esforço
    P
    Prazo
    IMEDIATO
  3. 3

    Parar de atualizar cadastro existente pela rota pública de agendamento e reduzir a resposta da confirmação a data e horário

    • SE-03
    • AP-02
    Responsável
    CTO
    Esforço
    P
    Prazo
    IMEDIATO
  4. 4

    Expiração, algoritmo e audiência no JWT

    • AP-01
    Responsável
    CTO
    Esforço
    P
    Prazo
    IMEDIATO
  5. 5

    Corrigir a CSP e acrescentar HSTS no vercel.json; conferir com curl -I

    • IN-01
    Responsável
    CTO
    Esforço
    P
    Prazo
    IMEDIATO
  6. 6

    Fazer as verificações pendentes nos painéis da Vercel, do banco e do GitHub e guardar as evidências

    • SE-09
    • DS-10
    • DS-11
    • IN-02
    • IN-03
    • IN-04
    • IN-05
    • IN-06
    • IN-07
    • IN-09
    • IN-10
    • IN-11
    • IN-14
    • DS-02
    • DS-07
    • DS-08
    • AP-03
    Responsável
    CTO
    Esforço
    P
    Prazo
    30_DIAS
  7. 7

    Termos de uso com cláusulas de operador para as clínicas, com a lista de suboperadores

    • OP-01
    • OP-03
    Responsável
    CEO + jurídico
    Esforço
    M
    Prazo
    30_DIAS
  8. 8

    Reunir e arquivar os DPAs da Vercel e do provedor do banco; examinar os termos e incorporar CPC onde faltarem

    • GV-09
    • TI-02
    Responsável
    CEO + jurídico
    Esforço
    M
    Prazo
    30_DIAS
  9. 9

    Processo de incidentes, com prazo de aviso às clínicas e comunicação à ANPD e aos titulares nos dados próprios

    • OP-04
    • GV-08
    Responsável
    CEO + CTO
    Esforço
    M
    Prazo
    30_DIAS
  10. 10

    Indicar encarregado (interno ou serviço externo)

    • GV-02
    Responsável
    CEO
    Esforço
    P
    Prazo
    30_DIAS
  11. 11

    Reescrever e publicar o aviso de privacidade dos tratamentos próprios e a política de cookies, com destinatários, transferência internacional, canal de direitos e canal de denúncia

    • DT-01
    • DT-03
    • DT-04
    • DT-07
    • TI-04
    • CK-07
    • BL-02
    • GV-06
    • DT-05
    Responsável
    CEO + jurídico; publicação pelo CTO
    Esforço
    M
    Prazo
    30_DIAS
  12. 12

    Registro das operações de tratamento, na forma completa, separando os papéis e com o mapa dos envios ao exterior

    • GV-01
    • TI-01
    • BL-02
    Responsável
    CEO + encarregado
    Esforço
    M
    Prazo
    30_DIAS
  13. 13

    npm audit, Dependabot, análise estática e varredura de segredos no CI

    • DS-02
    • DS-07
    • DS-08
    Responsável
    CTO
    Esforço
    P
    Prazo
    30_DIAS
  14. 14

    Trilha de auditoria de acessos a dados de pacientes

    • SE-07
    Responsável
    CTO
    Esforço
    M
    Prazo
    30_DIAS
  15. 15

    MFA e limitação de tentativas no login e nas rotas públicas

    • SE-04
    • AP-03
    Responsável
    CTO
    Esforço
    M
    Prazo
    30_DIAS

Médio prazo (30-90 dias) 11 ações

  1. 16

    Confirmar que não resta uso próprio de dados da página de agendamento; se restar, elaborar o RIPD (prazo sugerido 30_DIAS, adiado pelo aceite de risco)

    • GV-03
    Responsável
    CEO + encarregado
    Esforço
    P (G, se o RIPD for necessário)
    Prazo
    90_DIAS
  2. 17

    Rotas de exportação e eliminação por paciente, para uso das clínicas

    • OP-05
    Responsável
    CTO
    Esforço
    M
    Prazo
    90_DIAS
  3. 18

    Devolução em lote e expurgo automático conforme os prazos das clínicas; expurgo de contas e logs próprios

    • OP-06
    • GV-12
    Responsável
    CTO
    Esforço
    M
    Prazo
    90_DIAS
  4. 19

    Política de retenção dos dados próprios, com as retenções legais, e procedimento de atendimento a pedidos, com registro de cada um

    • GV-04
    • GV-14
    • DT-02
    • DT-10
    Responsável
    CEO
    Esforço
    P
    Prazo
    90_DIAS
  5. 20

    Banner com categorias, texto que nomeie finalidades e terceiros e registro das escolhas no servidor

    • CK-04
    • CK-05
    • CK-06
    Responsável
    CTO
    Esforço
    M
    Prazo
    90_DIAS
  6. 21

    Corrigir o que as verificações pendentes revelarem (por exemplo, exportar os registros de acesso para guarda de 6 meses)

    • SE-09
    • DS-10
    • DS-11
    • IN-02
    • IN-03
    • IN-04
    • IN-05
    • IN-06
    • IN-07
    • IN-09
    • IN-10
    • IN-11
    • IN-14
    Responsável
    CTO
    Esforço
    M
    Prazo
    90_DIAS
  7. 22

    Rotas para ver, corrigir, exportar e excluir a conta do usuário da clínica

    • DT-06
    Responsável
    CTO
    Esforço
    M
    Prazo
    90_DIAS
  8. 23

    Política de segurança da informação e pasta versionada com as decisões de privacidade

    • GV-15
    • GV-16
    Responsável
    CEO + CTO
    Esforço
    M
    Prazo
    90_DIAS
  9. 24

    Validar o formato dos campos do agendamento; inventário das rotas públicas

    • SE-10
    • AP-05
    Responsável
    CTO
    Esforço
    P
    Prazo
    90_DIAS
  10. 25

    Declarar permissions mínimas no workflow e fixar actions e CLI por versão

    • DS-09
    Responsável
    CTO
    Esforço
    P
    Prazo
    90_DIAS
  11. 26

    Migrar para uma linha do Node.js com suporte e definir a rotina de atualização do runtime

    • IN-16
    Responsável
    CTO
    Esforço
    P
    Prazo
    90_DIAS

Longo prazo (90-180 dias) 3 ações

  1. 27

    Gerar SBOM a cada build

    • DS-03
    Responsável
    CTO
    Esforço
    P
    Prazo
    180_DIAS
  2. 28

    Revisar o aceite de risco do RIPD e repetir esta auditoria (/lgpd-saas), agora com acesso aos painéis, para medir a evolução

    • GV-03 e todos
    Responsável
    CEO + encarregado
    Esforço
    P
    Prazo
    180_DIAS
  3. 29

    Revisão semestral do aviso, dos contratos e do registro; treinamento básico de privacidade para a equipe, com registro; quadro de responsabilidades com os provedores; orientação às clínicas sobre o aviso delas na página de agendamento

    • DT-04
    • GV-01
    • OP-01
    • GV-17
    • IN-15
    Responsável
    Encarregado
    Esforço
    M
    Prazo
    180_DIAS

Cálculo do score

Cálculo do score por área no relatório de exemplo
ÁreaItensΣ(valor × peso)Σ(peso)score_areaPesoPeso ajustadoCobertura
bases_legais105,52522,012%16,67%100%
seguranca1415,04037,520%27,78%82,4%
direitos_titular80,5172,912%16,67%100%
governanca223,0555,512%16,67%100%
infraestrutura30,060,08%11,11%23,1%
apis_integracoes66,01637,58%11,11%100%
ai_llm———não aplicável8%——
eca_digital———não aplicável10%——
plataformas_digitais———não aplicável10%——
Total6330,015920100%100%82,9%

As três áreas sem objeto no escopo (sem IA no produto, sem público infantojuvenil, sem conteúdo de terceiros) foram declaradas não aplicáveis com evidência, e os pesos das seis restantes, que somam 72%, foram divididos por 0,72.

[12 × 22,0 + 20 × 37,5 + 12 × 2,9 + 12 × 5,5 + 8 × 0,0 + 8 × 37,5] / 72 = 19,649… → 20 → CRITICO

Informativos, fora da classificação: score técnico 29,6 e score documental 3,8. Leitura do próprio relatório: o código tem falhas pontuais e corrigíveis, mas quase nada do que a LGPD pede por escrito existe.

O teto por achado crítico não altera o resultado aqui, porque o score já está na faixa CRITICO. Nenhuma severidade foi reduzida pelo porte: há tratamento de alto risco (dados de saúde).

Pontos fortes

O relatório também registra o que está bem feito, sempre com evidência ENCONTRADA.

  • SE-01 · senhas com bcrypt, custo 12 (src/auth.js:5-8)
  • SE-02 · redirecionamento para HTTPS e HSTS de 1 ano no código da API
  • SE-05 · consultas parametrizadas e saída com textContent
  • DS-01 · segredos do pipeline em secrets do CI, sem eco em log
  • AP-04 · TLS na conexão com o banco
  • AP-06 · nenhuma chave no código nem no front-end
  • GV-07 · sede e contato no País publicados
  • CK-01 · banner com “Rejeitar” tão visível quanto “Aceitar”
  • BL-04 · coleta mínima nas contas dos usuários das clínicas

Funciona no assistente que sua equipe já usa.

O framework é o mesmo para todas as ferramentas; mudam só o lugar dos comandos e da skill opcional. Várias ferramentas podem conviver no mesmo projeto.

Assistente Destino (--target) Slash commands Skill
Claude Code Destinoclaude Slash commands.claude/commands/ Skillopcional · .claude/skills/
Cursor Destinocursor Slash commands.cursor/commands/ Skillopcional · .agents/skills/
VS Code + GitHub Copilot Destinovscode Slash commands.github/prompts/ Skillopcional · .agents/skills/
OpenCode Destinoopencode Slash commands.opencode/commands/ Skillopcional · .agents/skills/
Codex Destinoagents Slash commandsnão há; peça em linguagem natural Skillsempre instalada · .agents/skills/
Gemini CLI Destinoagents Slash commandsnão há; peça em linguagem natural Skillsempre instalada · .agents/skills/

Slash commands executam o framework modular (.agents/lgpd-enterprise-auditor/): você escolhe o cenário com /lgpd-saas, /lgpd-full-audit e os demais.

A skill (SKILL.md) é a versão autocontida da mesma auditoria: o assistente a carrega quando você pede, por exemplo, “faça uma auditoria LGPD deste projeto”. Para Codex, Gemini CLI e similares, o destino agents funciona assim.

O que ele faz, e o que ele não pode prometer.

Uma auditoria só é útil quando seus limites estão escritos. Estes são os do LGPD Enterprise Auditor.

Como funciona por dentro

  • Instalação local, por projeto

    O instalador copia arquivos para dentro do projeto e registra um manifesto por ferramenta. update, check e uninstall usam esse manifesto e nunca mexem em arquivos que não sejam do framework.

  • Instalador que você pode conferir

    Leia o script antes de rodar, fixe uma versão e confira o SHA256SUMS publicado em cada release. Sem conseguir consultar a última versão, ele não instala a branch main por conta própria.

  • Markdown, sem servidor

    O framework é um conjunto de instruções em texto. O relatório .html é um arquivo único, com política de segurança que bloqueia qualquer recurso externo.

  • Evidência antes de conclusão

    Nada é conforme sem prova, e cada achado cita a evidência, com arquivo e linha quando ela está no código. Isso permite que outra pessoa refaça a verificação e discorde com base em fatos.

Limites que você precisa considerar

  • Quem lê o código é o assistente

    A análise roda no assistente de IA que você escolher. O que acontece com o conteúdo lido segue as políticas e a configuração desse assistente e do seu ambiente, não do framework.

  • Só o que está ao alcance

    Painéis de nuvem, produção e contratos fora do repositório não são lidos. Esses controles ficam NAO_VERIFICADO, fora do score, e o relatório diz qual acesso falta. Abaixo de 80% de cobertura, o score é marcado como parcial.

  • Revisão humana é obrigatória

    O relatório é gerado com apoio de IA, a partir das evidências disponíveis. As conclusões dependem da completude e da atualidade dessas evidências e devem ser revisadas por quem responde pelo tratamento.

  • O relatório é confidencial

    Ele descreve falhas que podem estar abertas. Guarde-o fora de repositórios públicos, por exemplo numa pasta listada no .gitignore.

Não é parecer jurídico nem certificação. O LGPD Enterprise Auditor apoia auditorias de conformidade com a LGPD, mas não substitui a avaliação do encarregado (DPO) nem a assessoria jurídica especializada. Um score alto não garante conformidade nem segurança.

Um comando, na raiz do projeto que você quer auditar.

O instalador pergunta qual ferramenta de IA você usa e se quer a skill, mostra um resumo e instala tudo localmente. Ele baixa a última release, a mesma versão do framework que instala.

macOS, Linux, WSL e Git Bash

bash
curl -fsSL https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/latest/download/install.sh | bash -s -- install

Prefere ler o script antes de rodar?

bash · baixar, revisar e executar
curl -fsSL https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/latest/download/install.sh -o install.sh
bash install.sh install

Versão exata, com conferência de integridade

bash · releases a partir da v1.6.0
V=vX.Y.Z   # a versão desejada
curl -fsSLO "https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/download/${V}/install.sh"
curl -fsSLO "https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/download/${V}/SHA256SUMS"
shasum -a 256 --ignore-missing -c SHA256SUMS   # no Linux: sha256sum --ignore-missing -c SHA256SUMS
bash install.sh install --version "$V"

Em scripts e CI, sem perguntas

bash · não interativo
curl -fsSL https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/latest/download/install.sh \
  | bash -s -- install --non-interactive --target cursor --with-skill

Windows PowerShell

PowerShell 5.1 ou 7
powershell -ExecutionPolicy Bypass -Command "iwr https://github.com/BrunoLagoa/lgpd-enterprise-auditor/releases/latest/download/install.ps1 -OutFile $env:TEMP\lgpd-install.ps1; & $env:TEMP\lgpd-install.ps1 install"

As opções têm os mesmos nomes no estilo do PowerShell: -Target, -WithSkill / -NoSkill, -ProjectDir, -Version e -NonInteractive.

Atualizar, verificar e desinstalar

Ações do instalador
AçãobashPowerShell
Atualizar as ferramentas instaladas… | bash -s -- update… install.ps1 update
Verificar a instalação… | bash -s -- check… install.ps1 check
Desinstalar… | bash -s -- uninstall… install.ps1 uninstall

… é o mesmo prefixo curl …/install.sh ou iwr …/install.ps1 da instalação.

Depois de instalar, abra o assistente no projeto e rode /lgpd-saas ou o cenário que se aplica. Com o destino agents, peça a auditoria em linguagem natural.

Antes de executar

Leia o código do instalador. Os dois scripts têm as mesmas ações, opções e destinos.

Documentação

Perguntas frequentes

Não encontrou o que procurava? Pergunte nas Discussions do GitHub.

O que é o LGPD Enterprise Auditor?

Um framework open source que transforma um assistente de IA de programação em um auditor de LGPD orientado a evidências. Ele combina auditoria jurídica (LGPD e regulamentos da ANPD) e técnica (appsec, cloud, mobile, DevSecOps, IA/LLM), um modelo de severidade e score, um formato de relatório padronizado e comandos por cenário. Não é um aplicativo: são instruções em Markdown instaladas no seu projeto.

Para quais projetos ele é indicado?

SaaS web, sites e portais, aplicativos mobile, sistemas que usam IA/LLM, pipelines de CI/CD, plataformas acessadas por crianças e adolescentes e provedores com conteúdo de terceiros ou anúncios. É útil para times de engenharia e plataforma, segurança e AppSec, compliance e privacidade, consultorias de adequação e squads com IA generativa em produção.

Como funciona a auditoria?

O assistente lê o que o projeto já documenta, pergunta só o que falta, ativa os módulos do cenário e avalia todos os itens do catálogo desses módulos, cada um com evidência. Em seguida consolida severidade, score e classificação e grava o relatório com o plano de adequação.

Quais assistentes de IA são suportados?

Claude Code, Cursor, VS Code com GitHub Copilot e OpenCode, com slash commands e skill opcional. Codex, Gemini CLI e similares usam o destino agents: não há slash commands, e a auditoria é pedida em linguagem natural pela skill, que é sempre instalada.

O que significa o score de 0 a 100?

É o resultado de uma fórmula fixa: cada item aplicável vale 1, 0,5 ou 0 conforme o status e pesa de 1 a 4 conforme a criticidade. As áreas têm pesos fixos que somam 100%. A classificação segue as faixas:

  • 0–49: CRITICO
  • 50–69: BAIXO_NIVEL
  • 70–84: PARCIALMENTE_CONFORME
  • 85–94: ALTA_CONFORMIDADE
  • 95–100: EXCELENTE

Com um achado crítico aberto, a classificação não passa de PARCIALMENTE_CONFORME, qualquer que seja o número. O score mede o que foi avaliado com as evidências disponíveis, não a conformidade da organização como um todo.

Os resultados garantem conformidade com a LGPD?

Não. O relatório é gerado com apoio de IA, a partir das evidências disponíveis, e as conclusões dependem da completude e da atualidade delas. Controles fora do alcance do assistente ficam como não verificados, e um cenário direcionado não cobre todos os domínios. Use o resultado para priorizar e corrigir, com revisão de quem responde pelo tratamento.

O projeto substitui uma auditoria jurídica?

Não. Ele apoia auditorias de conformidade, mas não substitui a avaliação do encarregado (DPO) nem a assessoria jurídica especializada. O próprio relatório recomenda confirmar com a assessoria jurídica pontos como o enquadramento do agente de tratamento.

Como instalar e atualizar?

Rode o comando de instalação na raiz do projeto (veja Instalação). Para atualizar, verificar ou desinstalar, use o mesmo comando com update, check ou uninstall. Também é possível instalar manualmente, copiando .agents/lgpd-enterprise-auditor/ e os arquivos de commands/.

Como visualizar os relatórios?

O .md abre em qualquer editor ou no GitHub. O .html é um arquivo único que abre direto no navegador, funciona offline e traz filtros, busca, tema claro e escuro e versão para impressão. Para conferir um relatório gerado, rode python3 scripts/validate-report.py <relatorio.html> a partir de um clone do repositório. Veja o relatório de exemplo.

Como contribuir com o projeto?

Abra uma issue para bugs, melhorias e atualizações normativas, ou envie um pull request seguindo o guia de contribuição e o código de conduta. Vulnerabilidades seguem a política de segurança.

Mais visibilidade sobre riscos. Mais clareza para agir.

Instale no seu projeto, rode o cenário que se aplica e receba um plano que sua equipe consegue executar.

Explorar no GitHub Instalar agora Ler a documentação
  • Open source, licença MIT
  • Instalação local, por projeto
  • Sem servidor e sem cadastro
  • Relatório em .md, .html ou nos dois