O problema real: regular IA não é regular software
Quando o Olhar Digital publicou o artigo sobre os desafios de se regulamentar a IA no Brasil e no mundo, o ponto central me chamou atenção logo de cara: a IA deixou de ser coisa de laboratório. Eu vejo isso todos os dias no meu trabalho. Sistemas que eu mesmo coloco em produção hoje tomam decisões que afetam crédito, contratação, atendimento e conteúdo. E o problema é que o código que escreve “boa tarde” num chatbot e o código que nega um empréstimo têm o mesmo formato de arquivo, mas implicações regulatórias completamente diferentes.
Na minha experiência como dev, o que mata projeto não é a tecnologia — é a falta de clareza sobre quem responde quando o modelo erra. Em software tradicional, um bug é determinístico. Em ML, o sistema pode estar funcionando “corretamente” do ponto de vista técnico e mesmo assim ser injusto. Isso muda toda a lógica regulatória que conhecemos.
O cenário global: três modelos de regulação brigando
Tem três caminhos regulatórios principais acontecendo agora, e cada um impacta diferente quem desenvolve. Vou destrinchar cada um.
EU AI Act — o padrão que vai exportar regras pelo mundo
O AI Act europeu entrou em vigor em 2024 e tem aplicação escalonada até 2027. O que importa para nós, devs:
- Sistemas de “risco inaceitável” são proibidos (pontuação social, reconhecimento facial em massa em espaços públicos).
- Risco alto (saúde, educação, recrutamento, crédito, infraestrutura crítica) exige gestão de risco, documentação técnica, logs, supervisão humana e precisão auditável.
- Risco limitado (chatbots, deepfakes) exige transparência — o usuário precisa saber que está falando com IA.
- Risco mínimo (spam filter, jogos) tem poucas obrigações.
Isso é relevante porque você provavelmente não está na Europa, mas seu código vai ter que respeitar isso. Quando uma bigtech adapta produto global para conformar com o AI Act, ela não cria uma versão “Europa” — ela adapta o produto inteiro. É mais barato. Então o AI Act virou, na prática, padrão mundial.
EUA — fragmentação deliberada
Não tem lei federal de IA aprovada. O que existe é um patchwork de ordens executivas (a EO 14110 do Biden foi substituída pela EO 14179 do Trump, que afrouxou parte das regras) e regulação setorial (FDA para saúde, FTC para consumo, CFPB para crédito). Para um dev que publica modelo open-source ou SaaS global, isso vira pesadelo: a mesma feature é legal em um estado e crime em outro.
Brasil — o PL 2338/2023 e o vácuo prático
O projeto de lei mais maduro é o PL 2338/2023, que já passou pelo Senado e está na Câmara. Ele cria uma classificação de risco similar ao AI Act, exige avaliação de impacto algorítmico (AIA) para sistemas de alto risco, e dá à ANPD o papel de fiscalizar. Mas ainda não é lei, e detalhes técnicos (o que conta como “alto risco”, quem assina o AIA, formato dos logs) não estão definidos. Isso é um problema para mim e para você: enquanto a regra não vem, a jurisprudência vai sendo construída caso a caso.
Na prática: o que muda no seu código amanhã
Não importa se a lei brasileira passa hoje ou em 2027. O custo de fazer isso desde já é menor do que retrofit depois. Então vou te mostrar o mínimo viável de “IA regulável” que eu aplico nos meus projetos.
O coração de qualquer sistema de IA auditável é o log de inferência. Você precisa saber, em produção, qual entrada gerou qual saída, qual versão do modelo, qual confiança, e quem (ou o quê) autorizou a decisão. Sem isso,监管 diz “mostre os logs” e você não tem o que mostrar.
# audit.py — wrapper mínimo viável para inferência auditável
import json
import hashlib
import uuid
from datetime import datetime, timezone
from pathlib import Path
class AuditLogger:
def __init__(self, model_name: str, model_version: str, log_dir: str = "./audit_logs"):
self.model_name = model_name
self.model_version = model_version
self.log_dir = Path(log_dir)
self.log_dir.mkdir(exist_ok=True)
def _hash_payload(self, payload: dict) -> str:
# Hash do input para integridade sem expor PII
raw = json.dumps(payload, sort_keys=True, default=str).encode()
return hashlib.sha256(raw).hexdigest()
def record(self, input_data: dict, output_data: dict, confidence: float, human_override: bool = False):
entry = {
"id": str(uuid.uuid4()),
"timestamp": datetime.now(timezone.utc).isoformat(),
"model": {"name": self.model_name, "version": self.model_version},
"input_hash": self._hash_payload(input_data),
"input_size_bytes": len(json.dumps(input_data)),
"output": output_data,
"confidence": round(confidence, 4),
"human_override": human_override,
"regulatory_class": "high_risk" if confidence < 0.85 else "limited_risk",
}
log_file = self.log_dir / f"{datetime.now(timezone.utc).date()}.jsonl"
with log_file.open("a", encoding="utf-8") as f:
f.write(json.dumps(entry, ensure_ascii=False) + "\n")
return entry["id"]
# Exemplo de uso
logger = AuditLogger(model_name="credit-scoring-v3", model_version="3.2.1")
trace_id = logger.record(
input_data={"applicant_id": "A123", "income": 8500, "age": 34},
output_data={"decision": "approved", "score": 0.78},
confidence=0.78,
)
print(f"Trace registrado: {trace_id}")
Esse código é propositalmente simples. Ele resolve três coisas que o AI Act e o PL brasileiro exigem:
- Integridade — hash do input garante que ninguém adulterou a entrada depois.
- Rastreabilidade — cada inferência tem ID único e timestamp UTC.
- Classificação automática — modelos com baixa confiança viram sinal de “risco alto” e podem ser revisados por humano.
Se você trabalha com OpenAI, Anthropic ou qualquer API externa, dá pra adaptar em 10 minutos. Vale o investimento.
Erros comuns que devs cometem (e que vão virar problema regulatório)
Em consultoria e em revisão de código, eu vejo os mesmos equívocos. Anota aí:
- Confundir acurácia com justiça. Modelo com 95% de acurácia pode ser 30% pior para mulheres. Regulação moderna mede fairness, não acurácia agregada. Use métricas como demographic parity e equal opportunity.
- Não versionar datasets. Sabe qual foi a versão dos dados que treinou o modelo de crédito de 2023? Se você não sabe, o auditor também não vai. DVC, MLflow ou até Git LFS resolvem.
- Tratar log de IA igual log de API. Log de API guarda request e response. Log de IA precisa guardar versão do modelo, prompt completo, tokens, temperatura, e output. Sem isso, reprodução vira impossível.
- Esquecer do “humano no loop”. Sistemas de risco alto na Europa exigem supervisão humana significativa. Botão de “aceitar” não conta — precisa ter significado.
- Ignorar a transparência com o usuário final. No AI Act, falar com IA sem avisar o usuário é infração. “Olá, eu sou uma IA” não é detalhe cosmético — é requisito legal.
Por que isso interessa mesmo se você não trabalha com IA “pesada”
Se você usa GitHub Copilot, Cursor, ou faz chamada pra OpenAI no seu backend, você está dentro do escopo. A regulação não vai perguntar se você “treinou um modelo” — vai perguntar se você tomou decisão automatizada com impacto em pessoa. E aí entra: recomendar conteúdo, pré-aprovar cadastro, classificar ticket de suporte, decidir se um texto vai pra moderação… Tudo isso é “decisão automatizada”.
Segundo reportagem do Olhar Digital, o consenso entre especialistas é que a regulação de IA no Brasil vai seguir o modelo europeu, com adaptações. Ou seja, o que descrevi acima não é especulação — é planejamento baseado em tendência clara.
FAQ — perguntas que devs realmente fazem
Se eu uso API da OpenAI, sou responsável pelo que o modelo gera?
Sim. Quem implanta o sistema responde. A OpenAI responde pelo modelo base; você responde pelo uso que faz dele, pelos dados que envia, e pelo impacto em usuários finais.
Open-source vai ser proibido?
Não. Tanto o AI Act quanto o PL 2338 têm cláusulas para pesquisa, desenvolvimento e uso não-comercial. O que pode ser regulado é a distribuição de modelos de uso dual (civiar e militar) e a aplicação em domínios de risco alto.
Preciso de DPO/advogado especializado?
Se seu sistema toma decisão automatizada que afeta pessoas (crédito, RH, saúde), sim — pelo menos uma consulta inicial. Custa menos que um processo depois.
Como começar a se preparar sem virar compliance officer?
Mínimo viável: (1) inventário dos modelos em produção, (2) logs de inferência como o do exemplo acima, (3) política de revisão humana para outputs de baixa confiança, (4) aviso claro ao usuário sobre uso de IA. Isso cobre 70% das obrigações que estão vindo.
Quando o Brasil vai ter lei de IA?
PL 2338/2023 pode ser aprovado em 2025 ou 2026. Mas o “regulação de facto” já está acontecendo via ANPD, CDC digital e jurisprudência do TJSP e TJRJ. Não espere a lei.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se quiser, posso publicar a próxima parte com um modelo de avaliação de impacto algorítmico (AIA) em template pronto pra customizar — só pedir nos comentários.