Cibersegurança para devs: como cumprir NIS2 e AI Act 2026

Por que Cibersegurança Deve Estar no Product Backlog — Não Só no da TI

Quando o assunto é cibersegurança, a maioria das empresas — e dos próprios devs — ainda trata como problema do CISO, do DPO ou do time de infra. Esse é o erro que vai separar quem cresce em 2026 de quem vai pagar multas pesadas e perder contratos. Em setembro, no Porto, vai acontecer a conferência «Cibersegurança & Competitividade Económica na Era da AI», organizada pela Ordem dos Economistas, Ordem dos Advogados, SEDES e APECYS, com apoio da Câmara Municipal do Porto, Porto Digital e APDL. A escolha do tema não é coincidência: traduz uma mudança estrutural que afeta diretamente quem escreve código.

Na minha experiência, o que mata a competitividade de uma empresa de software não é falta de feature — é um incidente de segurança que vaza dados, uma multa do AI Act por uso opaco de modelo generativo, ou um cliente enterprise que cancela contrato porque o fornecedor não está em conformidade com a NIS2. Confiança digital virou feature de venda. Segundo o Sapo.pt, é exatamente esse o ponto de equilíbrio que a conferência quer debater: transformar obrigação regulatória em diferencial competitivo.

O Cenário Regulatório que Chegou Para Ficar

Temos três peças regulatórias em jogo simultâneo, e isso muda o trabalho de quem desenvolve:

NIS2 (Diretiva Europeia de Cibersegurança): já transposta para o regime jurídico português. Aumenta o escopo de empresas obrigadas — boa parte das PMEs de software que prestam serviço a sectores críticos entrou no radar, com multas que podem chegar a 10 milhões de euros ou 2% do volume de negócios anual.
AI Act (Regulamento Europeu de IA): em vigor desde 2 de agosto de 2025. Provedores e implantadores de sistemas de IA passam a ter obrigações de transparência, gestão de risco, qualidade de dados e supervisão humana. Sistemas de alto risco precisam de documentação técnica rigorosa.
Digital Omnibus: adiado para dezembro de 2027. Não significa que podemos relaxar — significa que vamos conviver por mais tempo com regras já aplicáveis enquanto o texto final é discutido.

O detalhe que pega muitos devs desprevenidos: o AI Act não fala só com quem treina modelos do zero. Se você consome a API da OpenAI, Anthropic, Mistral ou mesmo um modelo open-source self-hosted para tomar decisões que afetam pessoas (crédito, recrutamento, saúde, etc.), você pode ser considerado implantador de um sistema de alto risco. Isso muda completamente a responsabilidade jurídica sobre o seu código.

O Ângulo do Desenvolvedor: Confiança Digital Como DX

Quem programa há mais de uma década lembra como era vender software em 2010: bastava funcionar. Em 2026, vender software B2B — ou qualquer SaaS com clientes europeus — exige que o produto seja auditável, observável e explicável. Isso afeta diretamente a Developer Experience.

Na prática, vejo três dimensões que separam times maduros dos demais:

Segurança como código: SAST, DAST, SCA e verificação de segredos rodando no pipeline, não depois do deploy.
Observabilidade de IA: logs estruturados das chamadas a modelos, com rastreabilidade de qual prompt gerou qual output, qual modelo, qual versão, qual contexto.
Provenance de dados: saber de onde veio cada dado usado em treino, fine-tuning ou retrieval-augmented generation (RAG).

Quem constrói isso vira diferenciado. Quem não constrói vira gargalo de vendas — o cliente enterprise pergunta “têm SOC 2?”, “estão em conformidade com NIS2?”, “como vocês auditam o uso de IA?”, e o dev não sabe responder.

Na Prática: Um Setup Mínimo que Já Atende Boa Parte das Exigências

Não precisa montar um programa maduro de GRC no primeiro dia. Dê este passo-a-passo para um repo de aplicação:

Instale um detector de segredos no pre-commit (impede que AWS_SECRET_ACCESS_KEY chegue ao git).
Configure SAST leve em CI (CodeQL, Semgrep ou SonarCloud free).
Adicione um linter de manifests Kubernetes/Docker com referência ao CIS Benchmarks.
Centralize logs e habilite retenção conforme requisito (NIS2 fala em 6 meses para incidentes).
Documente a árvore de decisão: se um LLM é usado, anote modelo, propósito, dados de input e output.

Exemplo de configuração de pre-commit que já elimina 80% dos riscos de vazamento de credencial em repositórios típicos:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks
        args: ['--no-git', '--redact']
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']
  - repo: https://github.com/returntocorp/semgrep
    rev: v1.45.0
    hooks:
      - id: semgrep
        args: ['--config', 'p/owasp-top-ten', '--config', 'p/javascript']
        files: \.(js|ts|py|go|java)$
  - repo: https://github.com/pre-commit/mirrors-prettier
    rev: v3.1.0
    hooks:
      - id: prettier
        types_or: [javascript, ts, json, yaml]

Para auditabilidade de IA, um wrapper Python simples sobre qualquer cliente LLM já dá o básico de logging estruturado exigido pelo AI Act para sistemas de risco limitado:

import json
import hashlib
import time
from functools import wraps
from typing import Callable

def ai_audit_log(purpose: str, model: str):
    """Decorator para registrar uso de IA conforme requisitos de transparência do AI Act."""
    def decorator(func: Callable):
        @wraps(func)
        def wrapper(*args, **kwargs):
            payload = {
                "timestamp": time.time(),
                "purpose": purpose,
                "model": model,
                "model_version": kwargs.get("model_version", "default"),
                "input_hash": hashlib.sha256(
                    json.dumps(args[0] if args else "").encode()
                ).hexdigest(),
                "user_id": kwargs.pop("__user_id", "anonymous"),
            }
            # Sanitização: nunca logar PII em claro
            try:
                response = func(*args, **kwargs)
                payload["status"] = "ok"
                payload["output_tokens"] = len(str(response))
                return response
            except Exception as exc:
                payload["status"] = "error"
                payload["error_type"] = type(exc).__name__
                raise
            finally:
                with open("ai_audit.log", "a", encoding="utf-8") as f:
                    f.write(json.dumps(payload) + "\n")
        return wrapper
    return decorator

# Uso:
# @ai_audit_log(purpose="customer_support_summarization", model="gpt-4o")
# def summarize_ticket(text: str) -> str: ...

Isso não é “compliance theater”. É observabilidade útil que você vai querer de qualquer jeito quando um output de LLM sair estranho em produção.

Erros Comuns que Vejo Toda Semana em Times de Dev

Tratar segredos como “caso de infra”. Dev joga token no .env, commita o .env.example com valor real por descuido. Solução: secret manager (HashiCorp Vault, AWS Secrets Manager, Doppler) desde o dia um.
Confiar cegamente em LLM para código de produção. O modelo vaza padrões treinados em código vulnerável que estava no GitHub público. Todo output de LLM precisa passar por revisão humana e scanner automatizado. Sem exceção.
Logging de PII em claro. Logs são o primeiro lugar que um atacante olha após um acesso indevido. Mascarar emails, CPIs, números de cartão e números de processo no logger — não na API.
Ignorar a cadeia de suprimentos. 90% do seu código vem de dependências. Se você não roda npm audit, pip-audit ou equivalente em CI, e não fixa versões com renovate/dependabot, você está exposto. Foi assim que aconteceu o caso log4shell, e vai acontecer de novo.
Tratar AI Act como problema de “outro time”. Se você integra com um LLM, o seu código é parte do sistema de IA. A responsabilidade regulatória começa no PR, não no board.

Perguntas Frequentes

A NIS2 se aplica à minha empresa de software, mesmo sendo PME?

Depende do setor que você atende. Se fornece serviço a entidades de infraestrutura crítica, setor financeiro, saúde, energia, transporte ou administração pública, provavelmente sim. Mesmo fora desses setores, muitas PMEs entram no escopo como “fornecedor essencial”. Verifique o anexo da diretiva e o regime jurídico português — o limiar de funcionários e de faturação é mais baixo do que parece.

Uso a API da OpenAI para resumir tickets de suporte. Isso me coloca sob o AI Act?

Uso limitado com mínimo risco — sem decisões sobre pessoas — tende a ficar fora do regime pesado, mas as obrigações de transparência e logs continuam. Se o resumo virar insumo para decisão automatizada que afeta o cliente (por exemplo, encerrar o ticket automaticamente), aí o escopo cresce. Documente sempre modelo, propósito e dado tratado.

Vale a pena ir à conferência do Porto, mesmo eu sendo dev e não CISO?

Vale. Boa parte do conteúdo é regulatória, mas três dos workshops são eminentemente práticos: preparação da empresa para o AI Act, cibersegurança para indústria e distribuição, e cibersegurança para autarquias. Networking com advogados, economistas e seguradoras também abre portas para entender o lado de quem compra software — raramente visível para devs.

Como começar a colocar a casa em ordem se a empresa nunca teve preocupação com compliance?

Quatro frentes paralelas: (1) inventário de onde rodam IA e onde há dados pessoais; (2) política mínima de gestão de segredos + MFA em tudo + logging centralizado; (3) scan automatizado em CI; (4) um documento curto — uma página — descrevendo modelo de ameaça e controles. É o “nada luxuoso” que 90% das empresas nem têm.

“Confiança digital” é só marketing bonito ou tem impacto real em receita?

Tem impacto direto. Estudos do setor mostram que propostas B2B de software com selo SOC 2 + NIS2-ready fecham mais rápido e com ticket médio maior. Em 2026, perguntar “vocês estão em conformidade?” virou pergunta padrão em RFP. Quem responde “sim, com evidência” vence.

🚀 Leia mais no yurideveloper.com.br

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.