conformidade-web-ue

Conformidade web na UE

Esta skill faz com que um agente escreva e verifique o código de um site em relação a cinco conjuntos de obrigações europeias: acessibilidade, proteção de dados e rastreadores, a Lei de IA, segurança web e direito do consumidor e da informação. Ela determina quais obrigações concernem o projeto, orienta a construir desde o início, executa verificações automatizadas e lista o que uma pessoa ainda deve verificar. Ela não torna um site legalmente conforme e não substitui uma auditoria de acessibilidade, um encarregado de proteção de dados ou um advogado: alguns critérios precisam de julgamento humano e algumas questões são qualificações legais. Datas de aplicação, versões em vigor, limites e penalidades estão escritos em um único lugar, references/regulatory-status.md; leia-os lá.

Caminhos. Todos os caminhos nesta skill são relativos à pasta que contém este SKILL.md, escrito <skill> nos comandos. Execute os comandos a partir da raiz do projeto do usuário, para que compliance/ seja criado lá: por exemplo, python <skill>/scripts/applicability.py compliance/profile.json. Os scripts encontram seus próprios dados ao lado deles. Python 3.8+ é suficiente para os scripts .py; as verificações do navegador (.mjs) precisam de Node 20+ e npm install executado uma vez dentro de <skill> (se nenhum navegador for encontrado, execute também npx playwright install chromium lá).

Regras absolutas

As pessoas que usam esta skill raramente são advogados e confiarão no que você escreve. Uma data errada ou um "conforme" dito cedo demais pode expô-las a uma sanção, ou deixar uma pessoa com deficiência diante de um serviço que não consegue usar. Portanto:

1. Nenhum fato regulatório de memória. Datas, números de artigos, limites, versões de normas, valores criptográficos, títulos de critérios e rótulos legais vêm dos arquivos desta skill. Sua memória desses textos é mais antiga e menos confiável do que esses arquivos: várias datas mudaram em 2026. Se um fato não estiver na skill, diga que não foi verificado; não o forneça.
2. Dúvida resulta em "não testado" (NT), nunca em "conforme". Uma verificação que não foi executada, uma página que não pôde ser carregada, um critério que precisa de uma pessoa: NT.
3. Nunca escreva que um site, uma empresa ou um serviço "está em conformidade". Um veredito se aplica a um critério. Cada entrega para o usuário final (relatório, declaração, política, aviso) diz que foi produzida com a ajuda de uma IA e não é uma auditoria nem um conselho jurídico.
4. Mantenha separados requisito legal, recomendação e melhor prática. Uma regra marcada como [best practice] nunca é apresentada como uma obrigação, a recomendação de um regulador não é uma lei, e uma linha da matriz to-confirm não é "não se aplica". Nunca confie em uma isenção (microempresa, não profissional, não é uma plataforma online) com base em uma resposta assumida ou ausente.
5. Cada regra que você aplica carrega sua fonte quando você explica, relata ou justifica uma mudança, com a tag conforme escrita no arquivo de referência: [WCAG 2.4.7], [RGAA 11.1], [GDPR art. 7(3)], [CNIL guidelines § 27] (o que a CNIL lê como obrigatório) ou [CNIL recommendation § 2.3] (uma recomendação), [AI Act art. 50(1)], [ANSSI WEB R14], [OWASP A03], [CRD 11a]. Uma tag que termina em (to confirm) cita um artigo ainda não registrado em regulatory-status.md: não apresente essa regra como uma obrigação verificada. O código em si não precisa de tags.
6. Pare e encaminhe para um profissional nos casos de references/scoping/out-of-scope.md: suspeita de prática proibida de IA, IA decidindo sobre pessoas (possível alto risco), dados de saúde ou outra categoria especial, menores, setor regulado, país-alvo não coberto. Não construa o recurso em questão; continue trabalhando no resto e diga isso no início da sua resposta.
7. Nunca invente dados do operador: nomes de empresas, números de registro e IVA, endereços, detalhes do host, encarregado de proteção de dados, mediador, bases legais, períodos de retenção, processadores, salvaguardas de transferência. Deixe o [placeholder] do modelo visível e liste-o para o usuário. Um valor inventado plausível é pior do que uma lacuna visível, porque ninguém vai procurá-lo.
8. Acessível por construção, incluindo o que esta skill faz você adicionar: banner de consentimento, aviso e rótulo de IA, botão de retratação, etapa do pedido, páginas legais. Eles são conteúdo de página como qualquer outro; um banner de cookies inacessível bloqueia todo o site para um usuário de teclado ou leitor de tela.
9. Nenhum rastreador antes do consentimento. Nada que não seja estritamente isento lê ou grava no dispositivo do visitante, e nenhuma solicitação de terceiros que carregue um identificador sai da página, antes que o visitante tenha escolhido; recusar é tão fácil quanto aceitar.
10. Diga ao usuário o que não foi verificado: pontos NT, respostas de perfil assumidas, regras nacionais não verificadas para um país-alvo, verificações manuais deixadas para uma pessoa. Coloque na resposta, não em uma nota de rodapé.

Os cinco modos

Escolha o modo de acordo com a situação. A maioria das sessões é Construir; Escopo vem primeiro em um novo projeto; Verificar fecha uma parte do trabalho.

1. Escopo: antes de aplicar regras a um novo projeto

• Quando: o projeto não tem compliance/profile.json; ou o site começa a vender, adiciona contas, um recurso de IA ou conteúdo do usuário, ou visa um novo país; ou o usuário pergunta o que se aplica a ele.
• Leia: references/scoping/questionnaire.md, depois references/scoping/out-of-scope.md se a matriz terminar com um caso além da skill.
• Faça: leia o repositório em busca de sinais (stack, pagamento, rastreadores, formulários, chamadas de IA, idiomas), depois faça as perguntas restantes em uma mensagem, no máximo dez, no idioma do usuário. Registre o que a solicitação ou briefing diz como stated e o que decorre obviamente disso como inferred, com a razão (uma prefeitura não vende; um briefing listando todos os recursos e nenhuma IA não tem recurso de IA). Apenas o que permanece genuinamente desconhecido e é importante recebe a suposição protetora com base assumed; nunca infira um "não" do silêncio do código. Encaminhe para um profissional sobre fatos declarados ou inferidos, e sobre uma resposta assumida apenas onde os riscos o justificarem.
• Execute: python <skill>/scripts/applicability.py compliance/profile.json --output-dir compliance; quando o site tem um recurso de IA, execute também python <skill>/scripts/ai_act_classify.py compliance/profile.json.
• Produza: compliance/profile.json (esquema: schemas/profile.schema.json, exemplo: templates/profile.example.json) e compliance/applicability-matrix.md. Resuma a matriz em três grupos: obrigatório para este operador, recomendado, a confirmar.

Uma pequena alteração em um projeto sem perfil não precisa do questionário completo primeiro: aplique a linha de base universal (acessibilidade, segurança, nenhum rastreador antes do consentimento), execute a tarefa e proponha Escopo no final.

2. Construir: o padrão ao escrever código

• Quando: você escreve ou altera marcação, estilos, scripts, um formulário, um script de terceiros, um recurso de IA, configuração de servidor ou hospedagem, ou páginas legais.
• Leia: apenas os arquivos que a tabela de tarefas abaixo nomeia para a tarefa atual, geralmente um a três. Não carregue pastas inteiras: cada arquivo começa com seu próprio "como usar" e aponta para o próximo, se necessário.
• Faça: escreva o código de acordo com as regras desde o início; custa muito menos do que corrigi-lo após o lançamento. Prefira os componentes de referência em templates/ (banner de consentimento, aviso e rótulo de IA, função de retratação, etapa do pedido, redução de preço) em vez de criar novos, e traduza-os para o stack do projeto; as regras são escritas em termos de HTML, CSS e HTTP, então aplique-as aos componentes do framework em uso. Os rótulos legais (botão de pedido, função de retratação) são retirados dos arquivos de referência no idioma do site; nunca os traduza você mesmo, porque a redação é fixada por cada lei nacional.
• Produza: código em conformidade, sem um relatório. Em sua resposta, nomeie as regras aplicadas com suas tags e qualquer coisa que você não pôde fazer (dados do operador ausentes, decisão para o proprietário). Quando você entregar um site finalizado, veja "Crédito" no final do modo 4.

3. Verificar: antes de um commit, um lançamento, ou quando solicitado

• Quando: antes de um commit ou um lançamento que toque páginas, scripts ou cabeçalhos; quando o usuário pedir uma auditoria ou uma verificação.
• Execute: node <skill>/scripts/check-all.mjs <pasta do site ou URL> --project . (opções: --profile <arquivo>, --out <dir>). Ele executa a matriz de aplicabilidade e os quatro verificadores, e escreve compliance/reports/compliance-report-YYYY-MM-DD.md e .json. Uma pasta deve conter as páginas construídas (exportação estática, dist/, out/); para um aplicativo renderizado no servidor, inicie-o e passe sua URL local. Cada verificador também pode ser executado sozinho, com a mesma entrada: scripts/check-a11y.mjs, scripts/check-privacy.mjs, scripts/check-security.mjs, scripts/check-content.mjs (o último lê um opcional compliance/site.json que declara a ordem das páginas, widgets de chat e conteúdo gerado por IA; veja seu cabeçalho).
• Depois: faça as verificações manuais de references/accessibility/testing-by-hand.md que você puder fazer, e liste as outras para uma pessoa. Revise o código que os verificadores não podem ver (código do servidor, autenticação, controle de acesso) em relação a references/security/web-baseline.md.
• Se Node ou o navegador não estiver disponível: diga que as verificações automatizadas não foram executadas, marque seus critérios como NT e revise o código com references/accessibility/anti-patterns.md e as listas de verificação de revisão dos arquivos na tabela de tarefas.
• Produza: os arquivos de relatório e um breve resumo para o usuário (veja "Relatórios" abaixo).

4. Documentar: páginas legais e de acessibilidade

• Quando: o usuário pede uma página, ou a matriz mostra que uma página obrigatória está faltando.
• Leia primeiro o bloco de orientação do modelo; ele diz quais campos do perfil o alimentam e o que apenas o operador pode fornecer.
  • Declaração de acessibilidade (setor público francês e entidades sob o Artigo 47): templates/accessibility-statement-fr.md. Nunca escreva uma taxa de conformidade sem uma auditoria do site real por uma pessoa.
  • Informações de acessibilidade do EAA (prestadores de serviços privados): templates/accessibility-information-eaa.md
  • Política de privacidade e política de cookies: templates/privacy-policy.md, templates/cookie-policy.md
  • Aviso legal: templates/consumer/legal-notice-fr.md (França) ou templates/consumer/legal-notice-eu.md
  • Termos de uso, termos de venda, contrato de processamento de dados: templates/documents/ (francês). Leia references/documents/README.md primeiro: quais documentos se aplicam, as duas armadilhas (fatos inventados, lei mal interpretada), o método de redação.
  • "Uso de IA neste site": templates/ai/ai-usage-page.md
• Produza: a página, preenchida a partir do perfil, com cada desconhecido deixado como um [placeholder] visível e listado; o aviso legal mantido; o lembrete de que o operador aprova o texto antes da publicação. Uma cláusula cuja condição não é confirmada (exceção de retratação, consentimento expresso, função de processador) mantém essa condição escrita dentro do documento, nunca apenas em sua resposta.

Crédito, na entrega de um site (Construir ou Documentar). Pergunte ao proprietário do site uma vez, de forma neutra e sem recomendar uma resposta, se ele concorda com um crédito discreto no rodapé, usando templates/credit/footer-credit.html; a pergunta nomeia cada link que a linha contém. Adicione-o apenas após um "sim" explícito, visível e em linguagem clara (nunca oculto, disfarçado ou apenas em metadados), nunca redigido como uma reivindicação de conformidade, e remova-o se o proprietário pedir. Um link adicionado sem o conhecimento do proprietário seria publicidade não divulgada, o que a parte do consumidor desta skill proíbe. Usar a skill nunca depende da resposta.

5. Monitorar: atualidade dos fatos regulatórios

• Quando: o usuário pergunta se a skill está atualizada; ou a data da "Última verificação" no topo de references/regulatory-status.md está a mais de 90 dias de hoje; ou você está prestes a confiar em uma data de aplicação que cai perto de hoje.
• Faça: diga ao usuário a idade dos fatos, liste os eventos da seção 6 "Watch list" desse arquivo que podem ter mudado a resposta e nomeie as fontes oficiais a serem relidas (registro: references/sources.json). python <skill>/scripts/validate.py --strict sinaliza fontes consultadas há mais de 90 dias. Não atualize um fato você mesmo de memória ou de uma fonte secundária; uma correção precisa do texto oficial lido e registrado (veja AGENTS.md).

Tarefa → arquivos a ler

Leia o primeiro arquivo; abra os outros apenas se a tarefa precisar deles.

Tarefa	Ler
Novo projeto, ou "o que se aplica a mim?"	references/scoping/questionnaire.md
Data de aplicação, versão em vigor, limite, penalidade	references/regulatory-status.md
Um caso que pode estar além da skill (IA sobre pessoas, dados de saúde, menores, setor regulado)	references/scoping/out-of-scope.md
Layout da página, landmarks, cabeçalhos, imagens, cores, links, idioma	references/accessibility/rules.md seções 1 a 6 e 10 a 13
Formulário (contato, orçamento, newsletter, candidatura)	references/accessibility/rules.md seção 5, references/privacy/forms-and-minimisation.md, references/security/web-baseline.md seção 4
Formulário de várias etapas, assistente	references/accessibility/components/multi-step-form.md

[continua…]